JDK-8213097 : Unsupported method passed by SSV to earlier JRE version during ruleset hand-off.
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 8u191
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2018-10-26
  • Updated: 2018-10-29
  • Resolved: 2018-10-29
Related Reports
Duplicate :  
Description
ADDITIONAL SYSTEM INFORMATION :
Windows 7 Professional SP1 x64 
JRE8 Updates tested: 191 and 192
Deployment Ruleset rule:
	<rule>
		<id location="https://{SANITIZED}" />
		<action permission="run" version="1.6.0_24" />
	</rule>	


A DESCRIPTION OF THE PROBLEM :
Update 191/192 appears to have made the JarFile.ensureInitialization() method available for implementation in the Java.Util.JarAccessImpl class.

Update 191 JavaUtilJarAccessImpl.java source:

    public void ensureInitialization(JarFile jar) {
        jar.ensureInitialization();
    }

In previous versions, JarFile.ensureInitialization() is a private method, so this becomes a problem when SSV saves the state for hand-off when a rule is defined that requires an applet to be handed off to an earlier JRE that does not support this method.

REGRESSION : Last worked in version 8u181

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1 - Install a deployment rule set that specifies an applet is launched using an older java version.  In our case, the applet (E-business Suite) requires Java version 1.6.0_24.
2 - Launch the applet using Internet Explorer.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Applet loads using the defined earlier JRE version.
ACTUAL -
Applet fails to launch with exception java.lang.NoSuchMethodError: sun.misc.JavaUtilJarAccess.ensureInitialization(Ljava/util/jar/JarFile;) logged in the trace.

CUSTOMER SUBMITTED WORKAROUND :
Our only available workaround is to remove JRE version 1.8.0_191/192 and revert back to version 1.8.0_181.

FREQUENCY : always



Comments
This is similar to JDK-8213011, therefore closing as duplicate.
29-10-2018