Applet ClassLoaders and resources

A

Andrew Thompson

I am currently puzzling over some applet behavior, and
how to correctly emulate it.

The Appleteer(1) test tool was designed to allow loading of
multiple applets, and looks to provide the normal applet
methods that allow applets to interact.

After failing to load the inter-applet communication demo
at Real's HowTo(2), a prompt from Daniel Pitts(3) identified
the underlying problem as resulting from the applet classes
being loaded by separate URLClassLoaders (one for each
applet, in the case of Appleteer).

I thought at first that the answer was to create a single
URLClassLoader that references all resources listed in every
applet element on the web page, but this would also present
problems for identically named resources in different Jar
archives.

Having said that, neither IE 7, nor Moz 3.0.5 is the slightest
bit confused as to which resource belongs to which applet, as
can be seen in the simple applet that appears twice in the
test page(4).

The top applet reads the property/text from the top.zip, and
the lower applet reads the property from bottom.zip.

How do they do it, while still allowing applets to communicate?

(1) <http://pscode.org/appleteer/>

(2) <http://www.rgagnon.com/examples/java-0022.html>

(3) <http://groups.google.com/group/comp.lang.java.programmer/msg/
2334e3948b2bf631>

(4) <http://pscode.org/test/appletresource/applet.html>
 
A

Andrew Thompson

Andrew said:
After failing to load the inter-applet communication demo
at Real's HowTo(2), a prompt from Daniel Pitts(3) identified
the underlying problem as resulting from the applet classes
being loaded by separate URLClassLoaders (one for each
applet, in the case of Appleteer).  [...]
Having said that, neither IE 7, nor Moz 3.0.5 is the slightest
bit confused as to which resource belongs to which applet, as
can be seen in the simple applet that appears twice in the
test page(4).  [...]
How do they do it, while still allowing applets to communicate?

(This is a guess, but perhaps testable by writing applets that identify
their loaders...?)

Good point. I will investigate that further.
Perhaps a common class loader is created using the codebases of all
applets in the page, then each applet gets its own class loader using
the archive parameters, but backed by the common one.

The trouble with that theory (AFAIU) is that
all resources would be found by the 'parent' classloader, which would
be checked before
the more specific classloaders are checked.

Of course, more investigation, dumping the
details of the classloaders (as you suggest)
might help clarify.

Thanks for your thoughts.
 
A

Andrew Thompson

Steven said:
It later occurred to me that calling ClassLoader#getResource(String) for
various resources might be slightly more robust than guessing what kind
of ClassLoader you're dealing with.

I do not quite understand what you mean, beyond mentioning
that inspecting the classloaders was merely intended as a
debugging technique (at least, that is how I interpreted your original
suggestion).

As to getting at the resources, I will typically use
Thread.currentThread().getConextClassLoader().getResource()

I used to use the simpler form of
this.getClass().getResource()
, but comments by Sun staff on the Sun forums changed my mind.

I'll think more on the other comments you made before making
a reply to them.

As an aside, I just saw a link on the Sun forums that pointed to
<http://java.sun.com/j2se/1.4.2/docs/guide/misc/applet.html>

In that page, it has the nugget under the ARCHIVE attribute
description
that..
"NB: in JDK1.1, multiple APPLET tags with the same CODEBASE
share the same instance of a ClassLoader. This is used by some
client code to implement inter-applet communication. Future JDKs
may provide other mechanisms for inter-applet communication. ..."

Huhh. It seems directly relevant, and when my brain clears to the
point of doing some useful thinking, I will ponder it some more..
 
A

Andrew Thompson

It took some detective work but I learned the one who
gave that advice, "dietz333", was really Andy Herrick,
the top man of Java SE deployment at Sun.  A bit more
work and I found a working email address.  I've asked
him to clarify.  If I hear back I'll post his answer
(so Roedy can update the Java Glossary).

Good move. You are not the first to wonder
about that advice, and will surely not be the
last.
 
A

Andrew Thompson

(dietz333 on the context classloader)
Most likely this was due to a bug in Java 1.4.2 or 1.5.0
that no longer exists in JDK6 train. ....
So the upshot is, there is nothing wrong with either method!

Huhh. I am actually still doing some development
aimed at 1.5+ (the front-end) as well as using
1.4+ for extra/add-on APIs. As such, I'll stick
with that advice for some considerable time yet.

(..reconsiders) No, given it is the classloader intended
for loading app. classes and resources, I reckon I'll
stick with it as a matter of habit.

Thanks for reporting back.
 
A

Andrew Thompson

(..reconsiders) No, given it is the classloader intended
for loading app. classes and resources, I reckon I'll
stick with it as a matter of habit.

To expand on that. I can just picture a
bug report against 1.7+ complaining of
getting an inappropriate classloader using
getClass().getResource(), being closed as
'not a bug' with the advice ..
"Use T.cT().gCC()"
( I'm sick of typing it out fully ;)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top