Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #14280 > unrolled thread

Packages and Reflection in an Applet

Back to article view | Back to comp.lang.java.programmer

Contents

  Packages and Reflection in an Applet "Richard Maher" <maher_rj@hotspamnotmail.com> - 2012-05-05 13:25 +0800
    Re: Packages and Reflection in an Applet Arne Vajhøj <arne@vajhoej.dk> - 2012-05-05 17:30 -0400
      Re: Packages and Reflection in an Applet "Richard Maher" <maher_rj@hotspamnotmail.com> - 2012-05-07 20:47 +0800
        Re: Packages and Reflection in an Applet Arne Vajhøj <arne@vajhoej.dk> - 2012-05-08 22:14 -0400
    Re: Packages and Reflection in an Applet markspace <-@.> - 2012-05-05 14:45 -0700
      Re: Packages and Reflection in an Applet "Richard Maher" <maher_rj@hotspamnotmail.com> - 2012-05-07 20:54 +0800
        [OT] Poster's name (Was: Packages and Reflection in an Applet) Lew <noone@lewscanon.com> - 2012-05-08 05:32 -0700
          Re: [OT] Poster's name (Was: Packages and Reflection in an Applet) markspace <-@.> - 2012-05-08 07:43 -0700
            Re: [OT] Poster's name (Was: Packages and Reflection in an Applet) Jan Burse <janburse@fastmail.fm> - 2012-05-08 17:02 +0200
            Re: [OT] Poster's name (Was: Packages and Reflection in an Applet) Gene Wirchenko <genew@ocis.net> - 2012-05-08 09:26 -0700

#14280 — Packages and Reflection in an Applet

Hi,

I have an unsigned Applet that needs to obtain a Username/Password from the 
user (via generic dialog boxes outside of the web-page) and optionally, on 
successful login, display some "welcome" info from the server. To that end, 
I have come up with a rudimentary AWT interface that pops-up a couple of 
modal dialogue boxes. (There is also a "status" window that has bytes 
received/sent etc).

So, I have the default, fallback, rough-as-guts option for obtaining user 
credentials but would like to allow the consumers of my Applet to override 
the default and supply their own much slicker +/- localized UI. So I have 
the simple interface below that each prospective UI class must implement but 
I don't know what part packages/protection play in this scenario as well as 
reflection. If there are any people here with direct experience of the 
following conditions/questions I would be very grateful for their advice: -

1) Can a class loaded via Reflection (eg: myInter localGUI = 
(myInter)(class.forName("appletParameter").newInstance())) be in the same 
Package, and enjoy the benefits/protection of same, as the caller? Ideally 
here, the methods/variables/properties of the newly loaded class (albeit 
under the restriction of being loaded from the same codebase) being package 
private and not public? Again ideally, I do not want the methods in this GUI 
to be accessible from JavaScript but obviously accessible from my applet.

2) I'd expect the "tier3Client" implementing class (and any additional 
classes) to be supplied in a separate archive/JAR file and this will be 
located via the "archive=a,b,c" specifier (with "codebase_lookup" set to 
false). My "understanding" is that class.forName() will use the same 
classloader as the Applet and therefore I'm hoping that it will happily 
search through all specified JAR files looking for the requested class?

3) Are there any other restrictions/requirements or wil this just not work?

Cheers Richard Maher

/**
 * Copyright Tier3 (c) Software. All rights reserved.
 *
 * @author    Richard Maher
 * @version   1.0
 *
 */

package tier3Client;

interface Tier3UserDialog {

    boolean doCredentials();

    String  getUsername();

    String  getPassword();

    boolean isWelcomeRequired();

    void    doWelcome(byte[] t3IdBuf);

    void    doConsole(byte[]      t3IdBuf,
                      Tier3Logoff sourceSession,
                      String      codeHost,
                      int         portNum);

    void    updateRcvd(int bytes);

    void    updateSent(int bytes);

    void    showRefCnt(int pages);

    void    appendConsoleMsg(String msg, int color);

    void    appendConsoleMsg(String msg);

    void    closeConsole();
} 

[toc] | [next] | [standalone]

#14295

On 5/5/2012 1:25 AM, Richard Maher wrote:
> I have an unsigned Applet that needs to obtain a Username/Password from the
> user (via generic dialog boxes outside of the web-page) and optionally, on
> successful login, display some "welcome" info from the server. To that end,
> I have come up with a rudimentary AWT interface that pops-up a couple of
> modal dialogue boxes. (There is also a "status" window that has bytes
> received/sent etc).

Why not use Swing instead of AWT?

Or maybe even do it the Java 8 way with JavaFX?

> So, I have the default, fallback, rough-as-guts option for obtaining user
> credentials but would like to allow the consumers of my Applet to override
> the default and supply their own much slicker +/- localized UI. So I have
> the simple interface below that each prospective UI class must implement but
> I don't know what part packages/protection play in this scenario as well as
> reflection. If there are any people here with direct experience of the
> following conditions/questions I would be very grateful for their advice: -
>
> 1) Can a class loaded via Reflection (eg: myInter localGUI =
> (myInter)(class.forName("appletParameter").newInstance())) be in the same
> Package, and enjoy the benefits/protection of same, as the caller? Ideally
> here, the methods/variables/properties of the newly loaded class (albeit
> under the restriction of being loaded from the same codebase) being package
> private and not public? Again ideally, I do not want the methods in this GUI
> to be accessible from JavaScript but obviously accessible from my applet.

The loaded class can certainly be in the same package as the caller.

> 2) I'd expect the "tier3Client" implementing class (and any additional
> classes) to be supplied in a separate archive/JAR file and this will be
> located via the "archive=a,b,c" specifier (with "codebase_lookup" set to
> false). My "understanding" is that class.forName() will use the same
> classloader as the Applet and therefore I'm hoping that it will happily
> search through all specified JAR files looking for the requested class?

If you do not specify a classloader in the forName call (there is an
overload for that), then you will get the current classes classloader.

> 3) Are there any other restrictions/requirements or wil this just not work?

Will their jar and your jar be loaded from the same location?

Arne

[toc] | [prev] | [next] | [standalone]

#14358

Hi Arne,

Thanks as always for your replies.

"Arne Vajhøj" <arne@vajhoej.dk> wrote in message 
news:4fa59c0e$0$285$14726298@news.sunsite.dk...
> On 5/5/2012 1:25 AM, Richard Maher wrote:
>> I have an unsigned Applet that needs to obtain a Username/Password from 
>> the
>> user (via generic dialog boxes outside of the web-page) and optionally, 
>> on
>> successful login, display some "welcome" info from the server. To that 
>> end,
>> I have come up with a rudimentary AWT interface that pops-up a couple of
>> modal dialogue boxes. (There is also a "status" window that has bytes
>> received/sent etc).
>
> Why not use Swing instead of AWT?

That's the whole point. If someone wants to use Swing then I'm happy to 
plug-in the results. (Or a localized/foreign-language version, or a.n.other)

>
> Or maybe even do it the Java 8 way with JavaFX?

I'm sure JavaFX is appropriate for those who see fit to use it but it's a 
non-issue here.

>
>> So, I have the default, fallback, rough-as-guts option for obtaining user
>> credentials but would like to allow the consumers of my Applet to 
>> override
>> the default and supply their own much slicker +/- localized UI. So I have
>> the simple interface below that each prospective UI class must implement 
>> but
>> I don't know what part packages/protection play in this scenario as well 
>> as
>> reflection. If there are any people here with direct experience of the
>> following conditions/questions I would be very grateful for their 
>> advice: -
>>
>> 1) Can a class loaded via Reflection (eg: myInter localGUI =
>> (myInter)(class.forName("appletParameter").newInstance())) be in the same
>> Package, and enjoy the benefits/protection of same, as the caller? 
>> Ideally
>> here, the methods/variables/properties of the newly loaded class (albeit
>> under the restriction of being loaded from the same codebase) being 
>> package
>> private and not public? Again ideally, I do not want the methods in this 
>> GUI
>> to be accessible from JavaScript but obviously accessible from my applet.
>
> The loaded class can certainly be in the same package as the caller.

Cool. So they just point their classpath at my interface bearing JAR an it 
should all be good/doable.

I guess I'll have some Manifest issues getting the/my original JAR to look 
for the new gui.JAR or with the Multi-JAR codebase/archive Object attributes 
sort the classpath out automagically?

>
>> 2) I'd expect the "tier3Client" implementing class (and any additional
>> classes) to be supplied in a separate archive/JAR file and this will be
>> located via the "archive=a,b,c" specifier (with "codebase_lookup" set to
>> false). My "understanding" is that class.forName() will use the same
>> classloader as the Applet and therefore I'm hoping that it will happily
>> search through all specified JAR files looking for the requested class?
>
> If you do not specify a classloader in the forName call (there is an
> overload for that), then you will get the current classes classloader.
>
>> 3) Are there any other restrictions/requirements or wil this just not 
>> work?
>
> Will their jar and your jar be loaded from the same location?

Yep.

>
> Arne
>

Cheers Richard Maher 

[toc] | [prev] | [next] | [standalone]

#14438

On 5/7/2012 8:47 AM, Richard Maher wrote:
> "Arne Vajhøj"<arne@vajhoej.dk>  wrote in message
> news:4fa59c0e$0$285$14726298@news.sunsite.dk...
>> On 5/5/2012 1:25 AM, Richard Maher wrote:
>>> So, I have the default, fallback, rough-as-guts option for obtaining user
>>> credentials but would like to allow the consumers of my Applet to
>>> override
>>> the default and supply their own much slicker +/- localized UI. So I have
>>> the simple interface below that each prospective UI class must implement
>>> but
>>> I don't know what part packages/protection play in this scenario as well
>>> as
>>> reflection. If there are any people here with direct experience of the
>>> following conditions/questions I would be very grateful for their
>>> advice: -
>>>
>>> 1) Can a class loaded via Reflection (eg: myInter localGUI =
>>> (myInter)(class.forName("appletParameter").newInstance())) be in the same
>>> Package, and enjoy the benefits/protection of same, as the caller?
>>> Ideally
>>> here, the methods/variables/properties of the newly loaded class (albeit
>>> under the restriction of being loaded from the same codebase) being
>>> package
>>> private and not public? Again ideally, I do not want the methods in this
>>> GUI
>>> to be accessible from JavaScript but obviously accessible from my applet.
>>
>> The loaded class can certainly be in the same package as the caller.
>
> Cool. So they just point their classpath at my interface bearing JAR an it
> should all be good/doable.
>
> I guess I'll have some Manifest issues getting the/my original JAR to look
> for the new gui.JAR or with the Multi-JAR codebase/archive Object attributes
> sort the classpath out automagically?

I think specifying multi jar in the HTML is the way to go.

>>
>>> 2) I'd expect the "tier3Client" implementing class (and any additional
>>> classes) to be supplied in a separate archive/JAR file and this will be
>>> located via the "archive=a,b,c" specifier (with "codebase_lookup" set to
>>> false). My "understanding" is that class.forName() will use the same
>>> classloader as the Applet and therefore I'm hoping that it will happily
>>> search through all specified JAR files looking for the requested class?
>>
>> If you do not specify a classloader in the forName call (there is an
>> overload for that), then you will get the current classes classloader.
>>
>>> 3) Are there any other restrictions/requirements or wil this just not
>>> work?
>>
>> Will their jar and your jar be loaded from the same location?
>
> Yep.

That avoids some potential issues.

Arne

[toc] | [prev] | [next] | [standalone]

#14296

On 5/4/2012 10:25 PM, Richard Maher wrote:

> classes) to be supplied in a separate archive/JAR file and this will be
> located via the "archive=a,b,c" specifier (with "codebase_lookup" set to
> false). My "understanding" is that class.forName() will use the same
> classloader as the Applet and therefore I'm hoping that it will happily
> search through all specified JAR files looking for the requested class?


There *are* restrictions when running an applet regarding classloaders 
and class loading.  Basically the plug-in won't let you do anything that 
*might* be a threat to Java applet security.  I don't know if this 
applies to your current situation however.  I'd just make certain to 
have a backup plan in case this one ends up not working as well as you'd 
hoped.

[toc] | [prev] | [next] | [standalone]

#14359

Hi Mark,

"markspace" <-@.> wrote in message news:jo472b$qgt$1@dont-email.me...
> On 5/4/2012 10:25 PM, Richard Maher wrote:
>
>> classes) to be supplied in a separate archive/JAR file and this will be
>> located via the "archive=a,b,c" specifier (with "codebase_lookup" set to
>> false). My "understanding" is that class.forName() will use the same
>> classloader as the Applet and therefore I'm hoping that it will happily
>> search through all specified JAR files looking for the requested class?
>
>
> There *are* restrictions when running an applet regarding classloaders and 
> class loading.  Basically the plug-in won't let you do anything that 
> *might* be a threat to Java applet security.  I don't know if this applies 
> to your current situation however.

I'm not asking for another/different classloader and the loadee class is at 
the same codebase so I think/dream I'm good to go.

> I'd just make certain to have a backup plan in case this one ends up not 
> working as well as you'd hoped.

Yeah, it's probably a version 2 nice to have. The fallback plan is it all 
works with a vanilla AWT interface right now. I'm guessing ProGuard 
configuration could also be an issue? "-keep theInterfaces" and --keep only 
th emethods that implement the interfaces in a munged class? (The 3rd party 
would implement an interface that callsback into other class instance 
methods in the Applet. (eg: Tier3Logoff from a console button)

Anyway, I'm too happy about the threading/multiplexing model working now to 
worry about customization/localization.
>

Cheers Richard Maher 

[toc] | [prev] | [next] | [standalone]

#14405 — [OT] Poster's name (Was: Packages and Reflection in an Applet)

Richard Maher wrote:
> Hi Mark,
>
> "markspace"<-@.>  wrote ...

His name isn't "Mark".

His handle is "markspace". Not "Mark Space".

Some posters use handles instead of names.

In such cases it's not effective to use only part of the handle, because it 
isn't a name. Furthermore, if "markspace" were his name, you still have to 
make a leap to assume that "Mark" is a valid intimate form. It'd be like 
saying, "Hi, Le" to me.

Regardless, in markspace's particular case, his name isn't "Mark", so it's 
better to greet him with "Hi, markspace."

(FYI, conventional English grammar rules mandate a comma to set off a vocative.)

FWIW, "markspace" is a quintessentially geekish handle, referring as it does 
to the old days of teletypes. Full props.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#14410 — Re: [OT] Poster's name (Was: Packages and Reflection in an Applet)

On 5/8/2012 5:32 AM, Lew wrote:

> FWIW, "markspace" is a quintessentially geekish handle, referring as it
> does to the old days of teletypes. Full props.


As far as I know, it's much older than that.  In telecommunications it 
originally referred to Morse code, literally the marks and spaces on a 
telegraph tape.

More recently it was still used in various signaling to refer to encoded 
1's and 0' in electronic transmissions like the old phone modem encoding 
(300 baud, 1200 baud, etc.).  I'm not sure what the current state of the 
art is, since I haven't done anything that low-level since my course 
work 20 years ago.

[toc] | [prev] | [next] | [standalone]

#14413 — Re: [OT] Poster's name (Was: Packages and Reflection in an Applet)

Hi,

For annonymity the REF-ID of a post must also
obsfuscated, otherwise it becomes known which
news server is used.

markspace does also a good job here. I see:

Richar Mahers original post: <jo2dk4$mh$1@speranza.aioe.org>
Response by markspace: <jo472b$qgt$1@dont-email.me>
Response by Richard Maher: <jo8gmk$ubb$1@speranza.aioe.org>
Response by Lew: <job3od$p5b$1@news.albasani.net>

There is no host dont-email.me.

Bye

markspace schrieb:
> On 5/8/2012 5:32 AM, Lew wrote:
>
>> FWIW, "markspace" is a quintessentially geekish handle, referring as it
>> does to the old days of teletypes. Full props.
>
>
> As far as I know, it's much older than that. In telecommunications it
> originally referred to Morse code, literally the marks and spaces on a
> telegraph tape.

[toc] | [prev] | [next] | [standalone]

#14416 — Re: [OT] Poster's name (Was: Packages and Reflection in an Applet)

On Tue, 08 May 2012 07:43:35 -0700, markspace <-@.> wrote:

>On 5/8/2012 5:32 AM, Lew wrote:
>
>> FWIW, "markspace" is a quintessentially geekish handle, referring as it
>> does to the old days of teletypes. Full props.
>
>
>As far as I know, it's much older than that.  In telecommunications it 
>originally referred to Morse code, literally the marks and spaces on a 
>telegraph tape.
>
>More recently it was still used in various signaling to refer to encoded 
>1's and 0' in electronic transmissions like the old phone modem encoding 
>(300 baud, 1200 baud, etc.).  I'm not sure what the current state of the 
>art is, since I haven't done anything that low-level since my course 
>work 20 years ago.

     It was 20 milliamp.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web