JDK-6709297 : Wonderland does not install via webstart with 6u10 b21 or later
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 6,6u10
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows_xp
  • CPU: generic,x86
  • Submitted: 2008-05-31
  • Updated: 2010-11-04
  • Resolved: 2008-07-10
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 JDK 7
6u10 b27Fixed 7Fixed
Related Reports
Duplicate :  
JDK-6714839 - sealing violation: can't seal package com.sun.media.imageioimpl.stream: already
Relates :  
JDK-6595845 - Java 6 JavaWebstart increases footprint by factor 2
Description
A senior wonderland enginer reports :
----
A couple of brave community members have tried running, via webstart, Project Wonderland (http://wonderland.dev.java.net) with JDK 6u10 and both have run into the following exception

Caused by: java.lang.SecurityException: sealing violation: can't seal package javax.media.jai.operator: already loaded
    at java.net.URLClassLoader.defineClass(Unknown Source)
    at java.net.URLClassLoader.access$000(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)


This works fine under other versions of JDK 6 and JDK 5.

---

I can verify this is so starting with b21 that this webstarted app fails.
 
That build contains on;ly deployment fixes - a large number of them so
I'm not sure what the cause is.
Comments
EVALUATION problem is in com.sun.deploy.cache.CachedJarFile, method getManifest(). The first call to getManifest will trigger lazy initialization of manRef, which is a SoftReference to the manifest object for the JAR. However, after we did the initialization, we did not return the manifest, but just return null. Therefore the first call to getManifest will return null. In URLClassLoader.defineClass, it will see if the JAR has manifest and determine whether to definePackage with just the pkgname or with the pkgname, url and manifest. In this case, first time manifest we got is null, so definePackage is called with pkgname only. Next time the same package loads again, the manifest will be found, but the pkg is not sealed by definePackage, hence we get the sealing violation exception.
03-06-2008
SUGGESTED FIX CachedJarFile.getManifest should return manifest properly after manRef is initialized
03-06-2008