Skip to main content

What exactly is the specification for init(); start(); stop(); destroy() ??

20 replies [Last post]
demonduck
Offline
Joined: 2008-03-14
Points: 0

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

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
nheger
Offline
Joined: 2011-02-09
Points: 0

If you look at the API, all it says is that start and stop will be called as the user leaves / enters the page containing the applet.

http://java.sun.com/j2se/1.5.0/docs/api/java/applet/Applet.html

The specs for init and destroy are to inform the Applet that it has been loaded/will be destroyed. It doesn't say anything about preserving the JVM upon leaving the page. So the behavior you were relying on was never really part of an official API - it was a side-effect of the implementation.

The problem with Sun is that important things like this were never defined - they apparently didn't think about these things. So a lot of the Applet behavior that we are all relying on are a result of the implementations out there - often, there was no other way.

I suggest you look for an alternative solution that uses officially specified APIs to do what you want to do. If there are none, you are SOL because any workaround or hack that depends on a specific plug-in implementation is bound to break at some point.

As for saving state, it might be worth considering JavaScript and the JS - Java bridge, or session cookies, or something similar. If the Applet is signed it should be able to just save state to the hard disk. Maybe you can find a cheap way of saving state server-side. You could identify users by cookie and deliver the state as applet parameter... there are many ways, main thing is probably cost of implementation....

demonduck
Offline
Joined: 2008-03-14
Points: 0

> If you look at the API, all it says is that start and
> stop will be called as the user leaves / enters the
> page containing the applet.
>
> http://java.sun.com/j2se/1.5.0/docs/api/java/applet/Ap
> plet.html
>

Yes, well you cite the manual page for Applet. The documentation for milestone methods of the Applet lifecycle is different and can be found in many different places -- which is another discussion ...

Here's one example and nowhere do you see the specification that the JVM will be unloaded when the user simply leaves the page. It says stop() should be called when the user leaves the page. It does not say that destroy() should be called when the user leaves the page and it does not say that the JVM will be unloaded when the user leaves the page.

http://java.sun.com/docs/books/tutorial/deployment/applet/appletMethods....

I agree that because there is no explicit statement that the JVM will remain loaded as long as the browser session can be interpreted ambiguously but that is more of a dodge than anything else. The history of usage for the last 15 years would seemingly support the assertion that the JVM should stay loaded -- with caveats for different browsers since the browser implementers have make the final determination.

> As for saving state, it might be worth considering
> JavaScript and the JS - Java bridge, or session
> cookies, or something similar. If the Applet is
> signed it should be able to just save state to the
> hard disk. Maybe you can find a cheap way of saving
> state server-side. You could identify users by cookie
> and deliver the state as applet parameter... there
> are many ways, main thing is probably cost of
> implementation....

Well in my case saving state means saving a multi-megabyte decoded JPG image. That would be more like a world record wedding cake than a cookie.

I guess my point was; is and will be in the future that the current -- and continuously transitory -- engineering staff at SUN should not randomly and arbitrarily change features established by a long and consistent history just to make it "convenient" to achieve what should have been addressed years ago -- like setting JVM params in the applet tag.

It is disruptive and destructive to the greater Java community the existance and support of which is really the only rational for those jokers to have a job in the first place.

The tail is waging the dog here. They should not tell us what will be changed at their convenience. We should be telling them what is needed for the maintenance of carefully and expensively developed code.

seagram8
Offline
Joined: 2009-11-30
Points: 0

Hi - I ran into this too as my users complained that the new release does not load the applet screens as fast( because of the JRE load and unloading as they navigate ).

I was preserving applet password enable flags as they navigate the html, and lost this ability to retain a session password so to speak.

My work around is to load a browser and one applet screen, minimize both and never use these from the tray again. Start another browser session and now the JRE never unloads as they navigate.

You would think that in control panel, the java setup would have a way to "preserve browser JRE loading", rather than making this a browser specify change, IMHO.

Anonymous

Do you need all commands or can you do just one?

fabian1982
Offline
Joined: 2009-04-29
Points: 0

Hi,

I have more or less the same problem.
Sometimes the JRE unloads when I leave the page. But not always!! When I start my applet without starting any threads and URLConnections the applet is cached in the legacy life cycle cache.
When multiple threads are running.

Somebody starts the applet destroy thread. But I don´t know why???

Does anybody know the reasons why the applet destroy thread is called in an legacy lifecycle?

Message was edited by: fabian1982

kazssym
Offline
Joined: 2007-04-18
Points: 0

IMO, it must be just a [b]side-effect[/b] that you could use static variables to keep data over applet re-instantiation. So AppletContext.setStream and AppletContext.getStream have been added to fulfill the needs?

demonduck
Offline
Joined: 2008-03-14
Points: 0

It was never a side effect. Once a class is loaded into the JVM the class stays there even if there are no instances of that class. So all static variables of that class are always alive and retain their values. That's the way the JVM has always worked.

Now, in their infinite wisdom, they have made that very useful feature unreliable when applets are loaded into web pages. AppletContext.(set,get)Stream() have nothing to do with accessing static variables.

kazssym
Offline
Joined: 2007-04-18
Points: 0

Is there any specification that states applets are always loaded in a single JVM? I may have missed it, so point out one, please?

demonduck
Offline
Joined: 2008-03-14
Points: 0

I don't understand your question. Are you asking if parts of an applet can be loaded into different JVM's? That would be an odd thing to do.

kazssym
Offline
Joined: 2007-04-18
Points: 0

Are you sure any Java spec states that two instances of an applet are always loaded in a single JVM? If it is not stated as such, an implementation (e.g. the new Java Plug-in) is free to load a fresh copy of the same applet into a newly created JVM, and static variables will be cleared for each time.

IMO, static variables [b]just worked[/b] since it had been implemented to reuse the applet code for better performance, but it has never been required by any spec. So the new Java Plug-in could freely change how applets are loaded and instantiated, and it must not be a bug either.

demonduck
Offline
Joined: 2008-03-14
Points: 0

I have no idea what you are talking about. I wonder if you do...

andrewherron
Offline
Joined: 2008-04-03
Points: 0

kazssym could be right about the multi-jvm behaviour not being wrong according to the spec (I haven't read it myself).

It is, however, a regression; previously applets could rely on static variables to share state on a page. We can't rely on LiveConnect if we plan to support older browser / JVM combinations, so static variables were the only easy option. And now they're dead as well.

kazssym
Offline
Joined: 2007-04-18
Points: 0

It might be an old bug that we could use static variables to store data for the next applet instantiation and it is now fixed. :)

I can understand that you want to share information between several applet instances and it was possible by static variables in early days. But now you have been able to use AppletContext.setStream for that purpose (to keep data between applet instances) since JDK 1.4. See http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guid...

If you should want to support older implementations, you could check the existence of the new methods via the Reflection API at run time and switch the way how your applet works.

demonduck
Offline
Joined: 2008-03-14
Points: 0

You guys are having an interesting conversation about something. But not about the problem I posted. If you actually read my original post I am concerned with saving the state of the applet so I can reload the applet in it's original state.

(set,get)Stream assumes a "browser session". Well, there aint no browser session if the friggin JVM unloads is there?

You guys go ahead and talk amongst yourselves. You seem to be enjoying your own conversation so well...

andrewherron
Offline
Joined: 2008-04-03
Points: 0

Have you actually tried the Stream API? Admittedly I haven't, but the documentation kazssym linked to says:

> stream data and objects from one browser session so that they can be reused
> in subsequent browser sessions

[i]subsequent browser sessions[/i] implies that regardless of JVM unloading this allows applets to remember data when they reload. I plan to start making use of this myself, actually.

demonduck
Offline
Joined: 2008-03-14
Points: 0

> Have you actually tried the Stream API? Admittedly I
> haven't, but the documentation kazssym linked to
> says:
>
> > stream data and objects from one browser session so
> that they can be reused
> > in subsequent browser sessions
>
> [i]subsequent browser sessions[/i] implies that
> regardless of JVM unloading this allows applets to
> remember data when they reload. I plan to start
> making use of this myself, actually.

No I have not tried the Stream API. I've been using static variables which still work as they always have worked as long as the JVM doesn't crash. Did anybody read my first message?

You might want to glance at this thread --

http://forums.java.net/jive/thread.jspa?messageID=314755

But don't let that stop you from experimenting with the Steam API, I would be very interested in knowing your results. I just don't see how you can preserve state if your JVM crashes. But maybe there is real magic in the JVM.

BTW: When you click on the link in

http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guid...

You get a Page Not Found error that takes you down the garden path.

http://java.sun.com/javase/6/docs/technotes/api/index.html

Good luck on your experiments and be sure and let us all know how it works out when the JVM crashes or otherwise vaporizes.

andrewherron
Offline
Joined: 2008-04-03
Points: 0

As near as I can tell, with update 10 and above the JRE staying alive is no longer reliable. Along with supporting multiple JREs per page (I get one JRE per classpath instead of just a new classloader) they have a timeout that shuts down the JRE after the last thread finishes in order to save memory, or something.

That timeout has definitely been lowered in update 14.

demonduck
Offline
Joined: 2008-03-14
Points: 0

I think it's a bug but there's no way I could reproduce it regularly. Before I made some slight changes in my applet, the JVM/plugin would exit when I [b]RETURNED[/b] to the applet page. Now -- as I type -- the JVM/plugin is loaded in FF2 and it's just sitting there after I have left the applet page. So the applet is destroyed and the JVM/plugin is just sitting there waiting.

So I don't think there is a timout. I think the JVM/plugin exits because there is a bug. But it doesn't look like anyone from SUN cares -- why should they? Let Oracle deal with it...

andrewherron
Offline
Joined: 2008-04-03
Points: 0

If you're using FF2 then you aren't using the next gen plugin and there probably isn't a timeout because only the NGP supports multiple JVMs per page. If it's FF2-specific then it's probably a bug, but I'll be surprised if they fix anything in that old plugin code :)

demonduck
Offline
Joined: 2008-03-14
Points: 0

I thought I was clear when I said, "[i]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]."

So let me be more clear -- I saw the JVM/plugin exit on return to the applet page with 1.6.0.14 running in IE6/FF3/FF2. When I first saw the bug (JVM/plugin exiting) I though it was a problem with FF3 which is notoriously buggy and unstable. I had just upgraded to FF3 that day. And of course FF3 only runs the new plugin so this was clearly a bug that existed in the new plugin and probably the old plugin too.

I saw the exiting bug and uninstalled FF3 and reverted to FF2. Still saw the problem which happened about 2/3'ds of the time. Then I noticed that the Java console would display a ThreadDeath exception just before the console vaporized. I had some thread management stuff going on in my stop() method. I removed all that stuff and made a few more mod's to my applet to conform to the new applet lifecycle.

Basically I punted on the expectation that any browser would operate like the old applet lifecycle and call stop() when simply changing tabs or iconifying the browser and calling destroy() only when the browser exited and not when the page was changed.

And after I made those mods, then I stopped seeing the bug. So the bug is probably still there but I'm currently not seeing it.

So -- is the bug fixed because I don't see it. Or does the bug live on like a vampire in it's coffin?

I just don't know anymore...