JDK-7083682 : signed application that was succesfully run on Java 6 do not start on Java 7 if cache do not cleared
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2011-08-26
  • Updated: 2013-01-08
  • Resolved: 2012-01-16
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
7u4 b05Fixed 8Fixed
Related Reports
Relates :  
JDK-6979271 - Application fails to lanuch after upgrading to JRE7
Description
FULL PRODUCT VERSION :
 1.7.0-b147 Java HotSpot(TM) 64-Bit Server VM

ADDITIONAL OS VERSION INFORMATION :
Windows 7 x64

A DESCRIPTION OF THE PROBLEM :
I use jacob 1.14.3 library (http://sourceforge.net/projects/jacob-project) in my applicaton wich works fine with Java 1.6.0_26-b03 Java HotSpot(TM) Client VM  over Java Web Start. Application is properly signed by maven webstart-maven-plugin. Whan I try run it in Java 1.7 I got flowing Exception:

Caused by: java.lang.SecurityException: class "com.jacob.com.ComException"'s signer information does not match signer information of other classes in the same package
	at java.lang.ClassLoader.checkCerts(Unknown Source)
	at java.lang.ClassLoader.preDefineClass(Unknown Source)
	at java.lang.ClassLoader.defineClass(Unknown Source)
	at java.security.SecureClassLoader.defineClass(Unknown Source)
	at java.net.URLClassLoader.defineClass(Unknown Source)
	at java.net.URLClassLoader.access$100(Unknown Source)
	at java.net.URLClassLoader$1.run(Unknown Source)
	at java.net.URLClassLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(Unknown Source)
	at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(Unknown Source)
	at java.security.SecureClassLoader.defineClass(Unknown Source)
	at java.net.URLClassLoader.defineClass(Unknown Source)
	at java.net.URLClassLoader.access$100(Unknown Source)
	at java.net.URLClassLoader$1.run(Unknown Source)
	at java.net.URLClassLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(Unknown Source)
	at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.Class.getDeclaredConstructors0(Native Method)
	at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
	at java.lang.Class.getDeclaredConstructors(Unknown Source)

orginal jacob jar is not signed.


REGRESSION.  Last worked in version 6u26


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
using Java 1.6
Comments
EVALUATION see MR
20-12-2011
EVALUATION This is cache backward compatibilty issue. In 7, we changed the way we read and write signers map in cache index files to handle signed with jar root entries. This is incompatible with index files from 6. One option to fix would be to bump up cache version and detect cached signed jars with root entries to redo the jar signing validation and recreate the index file. Bump up priority as this might be a common problem when users upgrade to jre7.
20-10-2011
EVALUATION The following are received from customer: ---------------------------------------- I use Java 1.7 from Sun. My version is: Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) 64-Bit Server VM (build 21.0-b17, mixed mode) Please try run javaws http://jnlp.softproject.com.pl/lilou/lilou.jnlp with Java 1.6 and then run it with Java 1.7 (do not delete application from Java Control Panel - Java Cache Viewer. If I was try this, I got java.lang.SecurityException: class "com.jacob.com.ComException"'s signer information does not match signer information of other classes in the same package at java.lang.ClassLoader.checkCerts(Unknown Source) at java.lang.ClassLoader.preDefineClass(Unknown Source) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Unknown Source) at java.lang.Class.getDeclaredConstructors(Unknown Source) But when I delete apllication in Java Control Panel, and run it first in Java 1.7 it works fine in Java 1.7 and 1.6! I thing, problem happens when Java 1.7 downloads jars with JNLP ---------------------------------------------------------------- I have tested using our JRE 7u2, the application works fine. It looks like the issue maybe in our cache implementation, whatever we store in cache using JRE6 is not fully understanded by JRE7, at least some certificate information is missing, therefore JRE7 didn't quite understanding it. Because there is a workaround to clear cache before running JRE7, the application do start successfully, I have lower the priority to 4, and assign to Thomas for further evaluation in our cache implementation.
20-09-2011
EVALUATION I have contacted submitter to request testcase and more information.
19-09-2011
EVALUATION We likely need more information to be able to resolve this bug. Can we get pointer to the test app we can use to reproduce the problem in house?
28-08-2011