United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6840201 Regression: applet.destroy() is interrupted with jdk 6u10, run into completion with 6u7
JDK-6840201 : Regression: applet.destroy() is interrupted with jdk 6u10, run into completion with 6u7

Details
Type:
Bug
Submit Date:
2009-05-12
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2009-11-30
Component:
deploy
OS:
windows
Sub-Component:
plugin
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u17-rev (b08)

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
This is radiance case 66207990.
There is a difference in behavior between different jdk6 update release 
in applet.destroy() is called when browser is closed.

With 6u7, destroy() can run into completion, whereas with 6u10,
destory() is interrupted before the it is finished.

This could post a problem for cleaning up resources.


Steps to run the testcase (attached)
--------------------------
a. Copy the files to the document root of a web server.
b. Compile TestApplet.java
c. Load test.html on a browser.
d. Open the java console

After the applet is loaded, close the browser. When jre 6u7 is used, the
java console will have the following output :
Inside init
Inside start
Inside stop
Inside destroy
Before waitObj wait
After waitObj wait
Exiting destroy

When jre 6u10 is used, java console shows the following output :
Inside init
Inside start
Inside stop
Inside destroy
Before waitObj wait
java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at TestApplet.destroy(TestApplet.java:30)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
Exiting destroy

I read through the document at
http://java.sun.com/developer/technicalArticles/javase/java6u10/
and the release notes at https://jdk6.dev.java.net/plugin2/

There is a note that says
"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. "

But there is no specific information on what changes developers should expect
and code accordingly.
We have tested the disable of the "next-generation java plugin" already with the provided testcase and it did not solve the problem. 

import java.applet.*;

public class TestApplet extends Applet {
 
  public void init()
  {
      System.out.println("Inside init");
  }
    public void start()
  {
      System.out.println("Inside start");
  }
    public void stop()
  {
      System.out.println("Inside stop");
  }

  public void destroy()
  {
      System.out.println("Inside destroy");
      Object waitObj = new Object();
            try
      {
         synchronized(waitObj)
         {
             System.out.println("Before waitObj wait");
             waitObj.wait(2*60*1000);
             System.out.println("After waitObj wait");
         }
      }
      catch(Exception e)
      {
          e.printStackTrace();
      }
      System.out.println("Exiting destroy");
  }
} 

<HTML>
<HEAD></HEAD>
<BODY >
<OBJECT classid="clsid:CAFEEFAC-0016-0000-0010-ABCDEFFEDCBA"
        codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_6_0-wind
ows-i586.cab#Version=1,6,0,10"
        WIDTH="750"
        HEIGHT="600"
        HSPACE="0"
        VSPACE="0"
        ID="">
<PARAM NAME="TYPE"       VALUE="application/x-java-applet;jpi-version=1.6.0_10">

<PARAM NAME="CODEBASE"   VALUE=".">
<PARAM NAME="CODE"       VALUE="TestApplet" >
<COMMENT>
<EMBED SRC="" PLUGINSPAGE="http://java.sun.com/products/archive/j2se/6.0_10/inde
x.html"
        TYPE="application/x-java-applet"
        java_codebase="."
        java_code="TestApplet"
        WIDTH="750"
        HEIGHT="600"
        HSPACE="0"
        VSPACE="0"
        NAME=""
>
<NOEMBED>
</COMMENT>
</NOEMBED></EMBED>
</OBJECT>
</BODY>

</HTML>

                                    

Comments
EVALUATION

The behavior in 6u7 is a bug. Applets' lifecycle is controlled by browser and applets should not be given capabilities to run when its hosting document is destroyed by browser.

Since 6u10, both old plugin and new plugin enforce applet shutdown after a fixed amount of time (1000ms in old plugin and 200ms in new plugin) for applet to stop.

We realize that some applets need more time to clean up their resources. Since 6u18, we make the stop timeout value configurable through deployment.properties and <applet> parameter (see CR 6862078). Applets can have up to 3000 ms to stop before their threads will be interrupted.
                                     
2009-10-08
EVALUATION

new deployment property is deployment.javapi.stop.timeout and can have a value in miliseconds of between 200 and 3000.
The applet parameter applet_stop_timeout can also be set to change this value.
                                     
2010-04-01



Hardware and Software, Engineered to Work Together