Having added a shutdown hook to an Applet as per documentation, http://java.sun.com/j2se/1.5.0/docs/guide/lang/hook-design.html .
The applet is displayed in a Browser (Only tested for Internet Explorer 6 but this behaviour could also be exhibited in other browsers). The Shutdown hook fails to run when the applet is displayed in Internet Explorer and the browser is closed normally. The Shutdown hook only runs if you use the Appletviewer to display the Applet.

Please see the attached document for a test case.
Posted Date : 2006-06-21 00:22:07.0

N/A

I don't understand the complaint here. The description is very vague so here is my take to address the question/complaint:

Java Plugin follows the legacy applet lifecycle, it does not invent new thing.
AWT class AppletPanel manages the applet lifecycle, and plugin just follows it. AppletPanel forks a separate thread in a new thread group (thread "applet-[applet_class_name]" in applet thread group) to call the applet's init(), start(), stop(), and destroy() methods. Plugin runs in separate thread group ("Plugin Thread Group").
When the applet gets unloaded either due to page reload or going away, the applet's stop() and destroy() method get called from the AppletPanel thread. Since applet can be shutdown by destroying the browser window, the shutdown sequence should be carried out as fast as possible, and hence, these calls cannot be made synchroneous. Any zombie objects will get clean up eventually by GC.

Changing behaviors of applet's legacy lifecycle is a big deal and could affect many users out there. I don't see it makes sense as of now for us to put a timer in during applet destroying process to wait for user's applet's activities to carry out.

Therefore, user should not design any activity that takes long time to carry out during their Applet.stop().  In most commercial applets seen, Applet.stop() is usually not implemented by users.

It's in our plan to revisit applet lifecycle's robustness (not behavior) in Dolphin (7.0). If customer has a use case where current applet destroy behavior is inadequate, we can take a look and see if there's anything that we can do when working with applet lifecycle revamp in 7.0.  With that, we need:

- A testcase that show use case.
- Explanation of why current applet destroy process is not adequate for commercial use.
Posted Date : 2006-06-20 22:43:29.0

I temporarily set status to "incomplete" here until submitter/customer provide clearer explanation of the problem their facing during applet shutdown process.

If I do not hear from submitter/customer 2 weeks from today, this CR will be close as "not a bug".
Posted Date : 2006-06-20 22:47:00.0

What is the *.odt file format for the attachment?
Please send testcase in format that is easy for us to open, ie, html, *.java, *.class, or readme text file.
Please do this asap for this CR to get addressed in a timely manner.
Posted Date : 2006-06-26 23:32:14.0

Thanks, Roy, for sending the text contents of problem description.

I had reviewed the described scenario thoroughly. However, I don't view what described a bug for Java Plugin.
The "shutdownHooks" can only be granted during VM normal exit, not during VM abrupt termination.

When running the applet with "shutdownHooks" in AppletViewer, closing the applet window trigger VM normal exit, and therefore the hook can be carried through (provided all necessary security permissions are granted).

In Java Plugin, there is only one single instance of VM per the life of the browser session. Applet shutdown due to page-switch or page reload do not trigger VM exit as the VM still stay alive as long as the browser session is alive.
If the browser window itself is being killed, we do not have a normal exit of VM either. Rather, VM is terminated abruptly in this case and hence no shutdownHook can be granted.

I will discuss this with VM team on this for their suggestion and see if there's anything small we can do to remedy the situation in the meantime.

My concern is, in order for JPI to grant "shutdownHooks" during browser window shutdown, even in the case it's accomplishable, it would change our applet's lifecycle design dramatically.
In J2SE 7.0, we are planning on revisiting applet lifecyle. Perhaps, that will be a good time where we can look into "shutdownHooks" concept to see if it's something possible to support in Java Plugin.
Posted Date : 2006-06-27 02:31:00.0

As mentioned, it's part of Dolphin that we will redesign Applet Lifecycle and LiveConnect (jplan 427).
This bug belongs to the same category.
(Other related bugs for jplan 427 include: 5094962, 6391104, 6261184, 6256191, 4989386, 6373450, 6289379, 6196736)

Will be targeted to Dolphin.
Posted Date : 2006-08-03 17:02:03.0

not fixable in the current plugin. Shutdown hooks never run in the JVM embedded in the web browser since it is not exited cleanly. We might be able to make this work in the out-of-process plugin, but probably shouldn't guarantee that it works since shutdown hooks may cause conflict with the applet lifecycle.
Posted Date : 2007-07-23 18:58:04.0

need to try with new plugin and see if problem still exists
Posted Date : 2008-12-22 18:53:12.0

tested with new plugin, shutdown hook is now executed, but it looks like we didn't wait until the shutdown hook code to complete before we exit the jvm.  more investigation needed.
Posted Date : 2009-07-11 01:44:22.0

I have a case where a shutdown hook is needed by our company. We have an applet that creates a login session via a bean reference on a Weblogic application server. The session checks if a license is available and either allows or disallows that session to login. That session must be properly closed for the license to be released. The closing of the browser window leaves little to no time to call back to the app server and logoff the session and release the license. This is an open issue that we can only fix now by running a thread to check for abruptly discontinued sessions. This thread runs at an allotted time and thus does not guarranty that the license is returned within a timely fashion.

My Applet, using JSE6 using next gen plugin, is a converted JWS application used in enterprise situation (it talks to WebLogic). I found the applet.stop() and applet.destroy() cannot make *ANY* api call that would put the thread in a non-running state; the plugin would *IMMEDIATELY* exit the applet. My applet.stop() wants to wait for a worker thread to send a polite shutdown request to the server, but it cant because of this undocumented brute force hammer exit. A simple test case where the applet calls sleep(1) in stop() followed by a println statement shows the rude exit.