Posted by demonduck
on June 5, 2009 at 12:42 PM PDT
Note -- this seems to be a bug...
With the latest release --
Java Plug-in 1.6.0_14
Using JRE version 1.6.0_14-b08 Java HotSpot(TM) Client VM
In FireFox 2, if I start my applet, the JRE and old plugin stays loaded if I go to another page. When I return to the page, I can access a static variable that I use to work around the change from the old or legacy applet lifecycle to the new applet lifecycle.
Now with the new plugin each time the user goes to a new page the JRE is completely unloaded. And I can't save the state of the applet so the user has to reload everything. I see this behavior in IE6.
I *WAS* using a static variable to save state so that when the user returned to the applet, I could restart the applet in the same state as when I left it.
But with the new plugin, I can't do that because the whole JRE is unloaded and reloaded each time the user leaves the applet's page and comes back.
I thought that the new lifecyle was just that the applet was destroyed each time the user left the page -- now you've thrown in a new and catastrophic complication by completely dumping the JRE.
Why did you do that? Is this another bright idea you got at Happy Hour? Unloading the JRE does not make for a better user experience.
Reloading an applet -- which can be very big -- and losing the state of the applet is really not a good thing to do.
Is this new behavior documented anywhere? I don't see what you are trying to achieve. It certainly is not a better user experience.
This new (new to me) behavior really deprecates stop() and destroy() and in a broad sense start() is no longer needed since one could do everything in init().
If deprecating start(); stop() and destroy() is what you have intended all along -- why wasn't this discussed in the forums or at least announced?
It turns out that this is a possible bug. See next thread...
Message was edited by: demonduck