Applet lifecycle: what's the practical difference between init() & start(), and destroy() & stop()?

Matt McHenry picture Matt McHenry · Sep 7, 2010 · Viewed 7.9k times · Source

The javadoc and tutorial have information about the four applet lifecycle methods (init() -> start() -> stop() -> destroy()). But they talk mostly in abstract language.

What I'm looking for are concrete examples of when it makes a difference if I put my code in init vs start, and similarly for destroy vs stop. The only thing I've found so far is in the tutorial's description of the destroy method. It says:

Note: Keep implementations of the destroy method as short as possible, because there is no guarantee that this method will be completely executed. The Java Virtual Machine might exit before a long destroy method has completed.

(I'm a bit shocked that the above isn't in the javadoc.)

Edit: to be more specific: Can anyone provide a browser + JVM combo that, upon some specific action (switching tabs, hitting the 'back' button, etc.), invokes stop but not destroy (or start but not init)?

Answer

cHao picture cHao · Sep 7, 2010

init and destroy are called when the applet is loaded or unloaded, respectively. It's possible for a browser to load an applet and stop it, but not destroy it, when navigating around, switching tabs, etc.

start and stop are for pausing and resuming the applet, in the case above (when the applet becomes, or ceases to be, shown on a page).

I don't know if any browser actually does keep an applet loaded, so it may not matter much. But as far as i learned it, the general rule is:

  • init should get the applet ready to run, but not actually set it in motion. The applet should be in a "stopped" state upon return from init. (A stopped applet should be using as few resources as practically possible, and no CPU.)
  • start should start the applet running (starting threads, etc). It generally won't read params and reload images and all that, as that should be done in init.
  • stop should undo what start does...returning the applet to the "stopped" state, but leaving it able to start again. It should not undo any of init's work, as that would leave the applet unstartable if the functionality is properly separated.
  • destroy should do any final cleanup before the applet is unloaded. It basically undoes init. It should not stop the applet; that's stop's job, and should already be done before destroy is called.