Did the test - this does appear to be the case. Any thought as to how
this might arise?
>Did the test - this does appear to be the case. Any thought as to how
>this might arise?
How the browser works inside is its own business, but consider that
you can't very well recover the RAM from an Applet's static
code/fields unless you load it with a custom class loader.
Also consider that Applets running on different pages are not supposed
to see each other. So they should not be sharing common static
fields. I think they would have to be running under different class
loaders.
I have not yet taken the time to poke around to figure out exactly how
the various browsers work vis a vis multiple Applets per page, per
window, with tracking what really happens with destroy and init.
I have discovered I can communicate between Applets on the same page
with getAppletContext().getApplets(); and just directly calling
methods, all of which appears to happen on the same thread.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
porter - 10 Dec 2005 22:34 GMT
Hi,
Thanks for this - it's quite interesting. My applets are in the same
web page intentionally - the point is that one of them is third party -
I can't change it, but it does expose components of itself in its
Applet A.P.I. which theoretically allow me to interface to it.
As you say above, the class loader issue does not affect you when
calling methods - in my example, the 'Method' based reflection using
invoke worked just fine.
In follow up to the earlier messages I went back and tried tweaking my
applet definitions - If I ensure that the code base and archive
instructions in the applet tags are identical, then the class cast
works fine in firefox. I'll have to try out some other browsers.
Thanks
Jase
porter - 10 Dec 2005 22:53 GMT
Oh yeah - P.S> I havent had to use signed applets to get java
reflection to work - the third party Applet I'm using provides a
reflection based API that allows the extender to add in commands
implemented as classes but called either via a javascript call or by
calling execute() on the Applet . The Applet has no signing in it, but
I've had no problems deploying it as an untrusted applet? I'm only ever
accessing reflection classes from the associated web server, so that
may be why.