EVALUATION

see MR
                                     

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.
                                     

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.
                                     

EVALUATION

I have contacted submitter to request testcase and more information.
                                     

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?