Skip to main content

Lifecycle methods in new Plugin

17 replies [Last post]
Joined: 2007-02-22

According to the release notes (, one of the features of the new plugin is "improved applet lifecycle management":

"Calls to the applet lifecycle methods init, start, stop, and destroy are more deterministic and cross-browser behavior has been improved. The applet class loader cache and the legacy applet lifecycle, required for backward compatibility, are fully supported and the behavior of both has been improved."

Where can I find more information about this? Specifically, what is the expected behavior of the lifecycle methods running under the new plugin?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-03-14

I agree that zero sizing an applet should not influence the applet's lifecycle. An applet can be used to manipulate the DOM and to communicate with javascript, without having to display anything in the applet window.

CSS properties and changing of tabs/window should influence the applet lifecycle in a predictable way. In FF3 the applet is not even instantiated when it is inside a block with 'display: none' , which prevents me from calling methods on it from javascript. In IE7 the applet is instantiated, initialized and started. I can not call this predictable. This might be a FF bug, which is why I commented on a FF bugreport.

SUN have cooperated with Mozilla Foundation in making the new java plugin. If this is the result I think SUN should pay more attention to how different browsers call the applet's lifecycle method and make sure it is done in a consistent way. If JavaFX and regular java applets is ever to come into widespread use this is _very_ important.

It would be very exciting to be able to use applets together with javascript and CSS (AJAX), and perhaps to manipulate the DOM. For this to be a viable approach applets have to react to CSS properties in a consistent manner in supported browsers.

Joined: 2005-03-14
Joined: 2008-03-14

Perfect bug report!

But they won't listen. They will just close it and hope you don't notice and if you
do notice and say something they'll just explain it away. They'll sandbag you with
their reasons until you just throw up your hands.

Where do these people come from? Why do they thing they have the right to
change a long established lifecycle protocol? They are out of control.

I hope Java gets spun out of SUN to someone with good engineering practices like
HP or IBM or even Microsoft. Microsoft's JVM wasn't all that bad in it's time...

Joined: 2003-08-24


You bring up good points, but *please* tone down the insults.

I personally believe that it is perfectly reasonable to break backwards compatibility sometimes (applet stability such a case) but I agree with you that in this case the new applet lifecycle protocol seems incomplete.

I take more issue with the fact that the new protocol doesn't fire all the necessary events than with the fact that it breaks compatibility with the old protocol. For example, the Bugzilla issue brings up very reasonable expectations that applet start()/stop() would get fired when the applet becomes visible or invisible and destroy() when a tab is closed.

I would appreciate hearing a more detailed explanation from "those in the know" in at Sun.


Joined: 2008-03-14

We all are insulted everyday by the Java Dev Team's arrogance.

You've been sandbagged for two weeks over your simple requests about
the lack of documentation for deployJava.js. Why do you put up with that?

They will never do what is needed to be done and if pointing out the lack of respect
the Java Dev Team has for people who have made their jobs possible by supporting
and evangelizing Java for the last 10 years -- if that's a insult then so be it.

They have no right to change the applet's fundamental protocol and yet they do so
with a backhanded arrogance that would get any other engineer fired if they tried
to pull that same sort of behavior on their bosses.

You may be willing to put up with that kind of insulting behavior but I'm not.

The more detailed explanation from "those in the know" has already been given. Read
the thread. It's just more of the same...

Joined: 2007-02-22

I had assumed that the new plugin would ensure consistent behavior for these methods across all browser versions. I'm just trying to find out what that behavior is...

Joined: 2004-01-07

At least on Linux+FireFox3RC1 everything works as expected.

If destroy is really called as soon as the browser is iconified it would definitivly break my applet on the plantforms this does happen.

lg Clemens

Joined: 2007-02-22

I have noticed the same behavior. It is possible that the developers of the new plugin simply consolidated init()/start() and stop()/destroy() for some reason. I'd just like to find some definitive documentation on it.

Joined: 2008-03-14

> I have noticed the same behavior. It is possible that
> the developers of the new plugin simply consolidated
> init()/start() and stop()/destroy() for some reason.
> I'd just like to find some definitive documentation
> on it.

I really hope this is not true. That makes the life of an
applet developer (ME!) 10 times more difficult.

Tell me it isn't so...

Joined: 2008-04-03

Weirdness with start/stop/destroy has been around for years, the team I work on just took to completely destroying our applet at the slightest sign of the browser closing it (also necessary due to memory leaks in FireFox2).

Makes subsequent startup a bit longer but it's the only way to be consistent across browsers and platforms.

Not to mention I've seen browsers that occasionally call componentHidden(), stop() and destroy() off the swing thread.

Joined: 2005-03-14

I have had big problems with the difference in behavior between IE and FF when it comes to lifecycle management. I try to use JUpload together with extjs.

Extjs uses 'display: none' to hide the element and 'display: block' to show it. In IE it works fine, but in FF I cannot call applet methods from javascript after first hiding then showing it.

I did some experimentation with IE7 and FF3 and found that FF calls init() and start() first when showing the applet and calls stop() and destroy() when hiding it. The 'visibility: hidden' and 'visibility: visible' attributes had no effect on the applet lifecycle. Setting the size of the applet to 0 had no effect.

In IE7 the 'display: none' attribute had no effect, neither did any of the others.

My opinion is that an applet should call init() when loaded and start() when it become visible and stop() when it is hidden, and finally destroy() when the window/tab is closed. Neither IE7 nor FF3 have this behavior.

Is this a result of the 'browser wars' which gave us many incompatibility headaches? CSS, javascript and now it seems applets can be a pain to work with because of the numerous 'small' differences between browsers.

Joined: 2003-06-16

The lifecycle management is largely driven by compatibility constraints. To avoid breaking existing complex applets it is basically required to start the applet even if it is hidden and/or zero-sized. The current behavior of the new Java Plug-In in 6u10 should be very uniform on all supported browsers. If you find this to not be the case please file a bug and provide a test case.

Joined: 2008-03-14

But you broke compatibility when you changed the original applet lifecycle.

The original lifecycle called init(); start(); stop() and destroy() at specific times.

You changed that lifecycle to call init()/start() together and stop()/destroy() together.

Now you are telling us that you are concerned about compatibility problems -- non-existent
problems most likely -- with applets written using the new lifecycle????

Which applets are you concerned about? Can you provide us with a list of "complex
applets" that you are "basically required" to support?

Give us an example how calling stop() separately from
destroy() would cause compatibility problems. And why
wouldn't the group that maintains that applet be able
to address those problems? And why are those people's
needs more important than ours?

Why weren't you concerned about breaking compatibility with the original applet lifecycle.
And why are those "complex applets" more important than
my applets?

Again you dismiss, denigrate and rationalize away all our concerns just so you don't have
to take responsibility for your poor engineering practices.

And "...file a bug report..." is code for, " suck
on this and don't bother us...".

Joined: 2008-03-14

I submitted a bug report about this problem months ago. Naturally, trying to find it in the BugBase is impossible because the BugBase is a completely jumbled mess.

But at one time -- and I can't verify this either because Java documentation is a complete and utter mess -- the init() and start() methods were called at applet startup; the stop() method was called when the browser was iconified or a page turn occurred; and the destroy() method was only called when the browser was closed.

Now the stop() method is *NOT* called when the browser is iconified; the stop() *AND* destroy() methods are called on page turn forcing the init() and start() methods to be called when the page is returned to.

This is wrong behavior.

The init() and start() method should be called at applet start up.
The stop() method should be called on browser iconification or page turn.
The start() method should be called when returning to the page.
The destroy method should be called only when the tab or browser window is closed.

The way it is now, either the applet keeps on running which is not good if it is using a lot of cycles or it loses state unnecessarily and has to be restarted -- not good for word processing or image processing or a lot of other things.

I've put up a little applet that prints out the sequence of calls to init(); start(); stop(); destroy(); in the Java Console. It doesn't do anything else.

These methods used to be called correctly in early versions of Java but somehow that very good protocol became lost knowledge. It's time to return it...


Joined: 2008-04-03

I always thought that destroy() behaviour was controlled by the browser, not Sun. You don't even have to load a new page to see wildly different behaviour, just put an applet in a div tag and use display:none to hide it.

From memory, IE will just stop() the applet but FireFox and Safari will destroy() it at that point.

Joined: 2008-03-14

Could be. I can't remember exactly either. But I know that different browsers do call those four methods differently. As I recall, IE (ironically) did the best job of calling them at the appropriate time.

Anyone can try the applet I linked to. And if you want to set up your own test, feel free to snatch the jar file and make your own test.

Joined: 2004-11-17

Documentation for the new Java Plug-In can be found at:

Hope it helps,