JDK-6767160 : New plugin does not pick up jre installed by DT
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6u10
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-11-04
  • Updated: 2011-02-16
  • Resolved: 2009-01-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u12 b02Fixed
Description
FULL PRODUCT VERSION :
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Using Internet Explorer 6.  I have a page which runs an applet.  The applet is certified to run on 1.6.0_06, but 1.6.0_10 is currently installed.  I used the deployJava script functions to determine if 1.6.0_06 is installed.  If it isn't then then launch the 1.6.0_06 install.  The install completes successfully, but my applet does not start up after that.

If I close the browser and re-open  the applet will start successfully.

I tried adding deployJava.refresh() in the java script following the JRE install, but that did not help.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.  Install 1.6.0_10 JRE on machine.
2.  Remove 1.6.0_06 JRE from machine.
3.  Visit web page that uses java script to install 1.6.0_06 prior to starting an applet which requires that jre.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
JRE Install correctly
Applet should start
ACTUAL -
JRE installs correctly.
Applet does not start - applet window is white.

Must close browser and navigate to page again to get applet to work.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
<script src="http://java.com/js/deployJava.js"></script>

<script>
	var targetJRE = "1.6.0_06";

	var jres = deployJava.getJREs();

	// detect the jre and launch install if necessary
                    var patt1=new RegExp(targetJRE);
    
                    if (patt1.test(jres)==false)
                    {
	    deployJava.installJRE(targetJRE);
	    deployJava.refresh();
                    }
</script>

...

<Object Tag for applet>
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
restart browser following jre install.

Release Regression From : 6u6
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.
Comments
EVALUATION There are several issues in the new plugin: 1. On the client jvm side, the installed jre list need be refreshed when it can not find matching jre version. 2. If after refreshing, a matching jre is found, which indicates there is a new jre installed, client vm need notify the browser side (server) jvm to refresh installed jre list as well. The browser side jvm then knows how to launch the newly install jre. This can be done through the existing applet relaunch mechanism by passing a jreInstalled flag. 3. The current JREInfo class seems having a bug that does not clear out staled jre entries. For example, uninstallation of 6u6 does not remove the 6u6 entry from the deployment.properties. When the browser side JVMManager is instantiated, it is supposed to scan system installed JREs and remove invalid entries. This does not happen. 6u6 entry is listed in JREInfo jres even it does not exist on the system. This causes confusion and fails to relaunch. To workaround it, launch java control panel to clean up deployment.properties after unstall 6u6.
12-11-2008
EVALUATION <html> <script src="http://java.com/js/deployJava.js"></script> <h2> First runApplet using applet with specific targetVersion 1.6.0+</h2> <script> var attributes = {width:300, height:100} ; var parameters = {jnlp_href: 'applet6u12.jnlp'} ; deployJava.runApplet(attributes, parameters, '1.6.0'); </script> <h2> Test runApplet using applet with specific targetVersion 1.6.0_06</h2> <script> var targetJRE = '1.6.0_06'; deployJava.returnPage = document.location; if (!deployJava.versionCheck(targetJRE)) { deployJava.installJRE(targetJRE); } var attributes = {width:300, height:100} ; var parameters = {jnlp_href: 'applet6u6.jnlp'} ; document.write('<h3>invoking runApplet with targetVersion ' + targetJRE + '<h3><br>'); deployJava.runApplet(attributes, parameters, '1.6.0'); </script> </html> If 6u6 and 6u12 are installed, it will run the applet first in 6u12, then in 6u6 If 6u6 is not installed, it will install it, then run the applet in 6u12. since the Java Plugin was initialized before 6u6 was installed.
10-11-2008
EVALUATION further investigation shows problem may be in new plugin. When DT plugin installs new version, list of available JREs is not updated if new plugin is already loaded. This may result in applet loading with 6u10, or prompting for download of 6u6, when it was just installed.
10-11-2008
EVALUATION Can you include the full javascript you are using ? You do not show what you do after the install. Why do you use your own pattern matching instead of just calling deployJava.versionCheck(targetJRE) ? For both IE and FF this is working for me: if (!deployJava.versionCheck(targetJRE)) { deployJava.installJRE(targetJRE); } deployJava.runApplet(...) This is assuming the applet is configured to static version to targetJRE, the result should be running applet with latest java plugin (6u10 in your case) and targetJRE (6u6 in your case). /Andy
04-11-2008