JDK-8033779 : JRE 7u51 Plugin Failing to Run Older JRE Version < 1.6.0
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 7u51,7u55
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-02-04
  • Updated: 2014-11-14
  • Resolved: 2014-02-20
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 7 JDK 8 JDK 9
7u55 b10Fixed 8u11Fixed 9Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
JRE 7 update 51

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601

EXTRA RELEVANT SYSTEM CONFIGURATION :
Self-Sign/Sign the jar archive containing the Applet.
Self-Sign/Sign the Deployment rulesets

A DESCRIPTION OF THE PROBLEM :
A bug (id=6709839) (JDK-6697256) that was fixed as of the version JRE 6 update  10 can now be seen reappearing in JRE 7u51 (latest as of 1/30/2014). Due to the enterprise need several Java Applets designed to run with the JRE 5u12 are still needed. To ensure proper security the Deployment Rule Set is used. A test Applet was run without JRE 7 where it runs in IE 10 (32bit) with JRE5u12. Once the Deployment Rule Set is enforced the Applet failed to start even though two separate JRE consoles were seen opening up i.e. one for the JRE 7u51 and the other for the JRE 5u12, but no where any error message showed the actual reason of failure. Once the tracing and logging were enabled from the JRE 7u51 control panel then a similar error messages those once reported for bug_id=6709839 were seen again. As a proof of the bug reappearring, the JRE 7u51 was uninstalled in favor of JRE 6u10 and the new JRE 6u10 successfully handed over the runtime to JRE 5u12 by showing a dialog box that it was going to do just that. And once the Applet ran it printed the java version as 1.5.0_12 and not 1.6.0_10.

REGRESSION.  Last worked in version 6u43

ADDITIONAL REGRESSION INFORMATION: 
JRE 6u10

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
0. Instal JRE 5 u12 in the user worksatation
1. create a simple Java Applet (JApplet) that shows the java.version when it runs.
2. compile the Applet with JDK 5 u 12 (Strictly)
3. Deploy to test in IE (it should appear)
4. Install JRE 7u51 and create Deployment Rule Set as below
<ruleset version="1.0+">
	<rule>
		<id location="{you applet location}"/>			
		<action permission="run" version="1.5.0_12" />					
	</rule>
</ruleset>


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
1. The Applet should run showing java version as 1.5.0_12

ACTUAL -
1. once run in IE observe two JRE console opening up (of course set them to show up during runtime) but the Applet will not run.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
No Error message, until the tracing and logging is enabled from the Java Control Panel where the error messages are similar to bug_id=6709839

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
package test.applet;

===HTML CODE====
<html>
<body>
<OBJECT
     classid="clsid:CAFEEFAC-0015-0000-FFFF-ABCDEFFEDCBA"
     width="200" height="200">
     <PARAM name="code" value="test.applet.MyApplet">
	 <PARAM name="archive" value="myapplet.jar">
	 <param name="java_version" value="1.5.0_12"/>
</OBJECT>
</body>
</html>

===JAVA CODE=====
package test.applet;
import java.awt.*;
import javax.swing.*;

public class MyApplet extends JApplet
{
	public void paint(Graphics g)
	{
		try
		{
			String java_version=System.getProperty("java.version");
			g.drawString("Java Version = "+java_version,20,50);
		}catch(Exception e)
		{
			e.printStackTrace();
		}		
	}
}
=======================================
Self-sign/Sign the myapplet.jar before deploying.
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Install JRE 6u10 and the new JRE 6u10 will hand over the runtime to JRE 5u12 successfully by showing a dialog box that it was going to do just that bypassing the greater need of using Deployment Rule Sets.


Comments
Does this need a fix in JDK 9 ? If so, please create a 9 backport! (or add 9-na)
14-04-2014

Although this does fix one problem using 1.5.0 versions of java with 7u55 deployment code, the other problem still occurs, preventing you from running some signed applet (see testcase: http://oklahoma.us.oracle.com/www/tests/javaws/certtests/1.5/ ) plugin will still sometimes call getJarValidationState() after relaunch into 5, which is not properly implemented for pre 1.6.0 jre. (not sure what circumstances cause this test to fail here, and other signed applets to run)
17-02-2014

which fix caused this regression ?
17-02-2014

Crucible review is at https://java.se.oracle.com/code/cru/CR-JDK7UCPU-253
10-02-2014

Changing sun.deploy.security.ruleset.RuleSetParser.parse() from SAXParserFactory spf = SAXParserFactory.newInstance( "com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl", null); to SAXParserFactory spf = Config.isJavaVersionAtLeast16() ? SAXParserFactory.newInstance( "com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl", null) : SAXParserFactory.newInstance(); solves the problem
10-02-2014

com.sun.deploy.security.ruleset.RuleSetParser.parse uses SAXParserFactory.newInstance(String factoryClassName, ClassLoader classLoader) method which was introduced in Java 6 only.
10-02-2014

The workaround mentioned is the bug description is not a workaround since to run applets in Java 5 VM it suggests uninstall 7u51/55 and use 6u10 instead.
10-02-2014

Catching and ignoring previous exception results in the new one with the same reason security: Expected Main URL: http://localhost:8080/TestJava15/myapplet.jar basic: error: javax.xml.parsers.SAXParserFactory.newInstance(Ljava/lang/String;Ljava/lang/ClassLoader;)Ljavax/xml/parsers/SAXParserFactory;. java.lang.NoSuchMethodError: javax.xml.parsers.SAXParserFactory.newInstance(Ljava/lang/String;Ljava/lang/ClassLoader;)Ljavax/xml/parsers/SAXParserFactory; at com.sun.deploy.security.ruleset.RuleSetParser.parse(RuleSetParser.java:61) at com.sun.deploy.security.ruleset.DeploymentRuleSet$1.run(DeploymentRuleSet.java:211) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.security.ruleset.DeploymentRuleSet.initialize(DeploymentRuleSet.java:198) at com.sun.deploy.security.ruleset.DeploymentRuleSet.getDRS(DeploymentRuleSet.java:150) at com.sun.deploy.security.ruleset.DeploymentRuleSet.findDRS(DeploymentRuleSet.java:141) at sun.plugin2.applet.Applet2Manager.getMainDeploymentRuleSet(Applet2Manager.java:460) at sun.plugin2.applet.Applet2ClassLoader.getDeploymentRuleSet(Applet2ClassLoader.java:836) at sun.plugin2.applet.Plugin2ClassLoader.isTrustedByTrustDecider(Plugin2ClassLoader.java:611) at sun.plugin2.applet.Plugin2ClassLoader.getPermissions(Plugin2ClassLoader.java:426) at sun.plugin2.applet.Applet2ClassLoader.getPermissions(Applet2ClassLoader.java:729) at java.security.SecureClassLoader.getProtectionDomain(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.defineClassHelper(Plugin2ClassLoader.java:1149) at sun.plugin2.applet.Plugin2ClassLoader.access$100(Plugin2ClassLoader.java:59) at sun.plugin2.applet.Plugin2ClassLoader$1.run(Plugin2ClassLoader.java:1129) at java.security.AccessController.doPrivileged(Native Method) at sun.plugin2.applet.Plugin2ClassLoader.findClassHelper(Plugin2ClassLoader.java:1089) at sun.plugin2.applet.Applet2ClassLoader.findClass(Applet2ClassLoader.java:161) at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Plugin2ClassLoader.java:273) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Plugin2ClassLoader.java:203) at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Plugin2ClassLoader.java:184) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Plugin2ClassLoader.java:853) at sun.plugin2.applet.Plugin2Manager.initAppletAdapter(Plugin2Manager.java:2512) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Plugin2Manager.java:1634) at java.lang.Thread.run(Unknown Source)
10-02-2014

Trying 7u55-b06 java.lang.NoSuchMethodError: javax.xml.parsers.SAXParserFactory.newInstance(Ljava/lang/String;Ljava/lang/ClassLoader;)Ljavax/xml/parsers/SAXParserFactory; at com.sun.deploy.security.ruleset.RuleSetParser.parse(RuleSetParser.java:61) at com.sun.deploy.security.ruleset.DeploymentRuleSet$1.run(DeploymentRuleSet.java:211) at java.security.AccessController.doPrivileged(Native Method) at com.sun.deploy.security.ruleset.DeploymentRuleSet.initialize(DeploymentRuleSet.java:198) at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Plugin2Manager.java:1605) at java.lang.Thread.run(Unknown Source)
10-02-2014

not really related to DRS (problem can be seen at medium security level w/o DRS). You can test (after installing 1.5.0_12, or any JDK 5 version.) with certtests at: http://oklahoma.us.oracle.com/www/tests/javaws/certtests/1.5/ The problem seems to be new code that was added to Plugin2ClassLoader to call TrustDecider.getJarValidationState(). unlike TrustDecider.isAllPermissionsGranted, getJarValidationState does not have provisions for pre-1.6 versions of java, and in these cases, just returns a new ValidationState(), so call to Plugin2ClassLoader.isSignedByTrustedCA will always return false, or throw an exception. to fix, would need to implement the case where haveValidatorSupport() is false in getJarValidationState(), as it is in isAllPermissionGranted(). Then continue testing 1.5 to see where next we have broken 1.5 platform support in plugin.
06-02-2014

A webbug that Dev or deploy sustaining can best evaluate.
06-02-2014