Question

Where I work they use the AppletContext.showDocument(URL) method when a user logs off our application, which is an applet, providing the desired logoff JSP. But they also have code that says if for some reason they are unable to get an AppletContext to simply call the Applet.destroy() method.

We are using a thin client architecture which means that we essentially have a bunch of dumb terminals connected to a server. I mention this because we will often have dozens if not 100’s of instances of JVMs running – one for each applet.

Inside the destroy() method they dispose of all resources they acquired and then get a reference to Runtime and call runFinalization() and gc() – but it does not do a System.exit() or equivalent.

Questions

1. I understand that frees up resources and leaves you on the same web page but what does it do to the JVM that was running the applet?
2. If I add a call to System.exit() at the end of the destroy() what will it do to the other JVMs that are running on the thin client server?

Answer 1

For context, this is all necessary because while a page is active browsers (or the Java plugin, or both) hang on to your applet instance. Even if you remove it from the DOM or try other tricks to release that memory, until you navigate to a different page your applet instance is retained so you need to fully clean up in destroy(). I’ve done memory profiling which shows it’s referenced in native code somewhere.

To answer your questions:

1. This depends on your version of Java. As of Java 6 update 10 (with the next-gen plugin) after a period of time with no applets running Java will shut itself down. This timeout has appeared to get shorter as the JVM startup time has decreased in the last year or two.
2. I don’t believe applets (even signed ones) are allowed to call System.exit(). If it was allowed though, on modern browsers it would kill the instance of the JVM for that browser, none of the others. In the past it would’ve been likely to shut the entire browser down 🙂

EDIT:

Actually there’s more to the story of Answer 1… that’s true everywhere except OS X, where the next-gen plugin wasn’t the default until somewhere around 6u27 (On 10.6 it was Java for OS X update 5, and 10.7 from day 1).