JDK-6667564 : bootclasspath/classpath search problem
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2008-02-25
  • Updated: 2010-09-08
  • Resolved: 2008-05-12
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
6u10 b21Fixed
Description
for kernel vm/jre:

java -cp "c:\Program Files\java\jre6\lib\javaws.jar";"c:\Program Files\java\jre6\lib\deploy.jar"
-Dkernel.debug=true -Dkernel.background.download=false com.sun.javaws.Main -shortcut -uninstall 

fails.

while:

java -Xboothclasspath/a:"c:\Program Files\java\jre6\lib\deploy.jar" -cp "c:\Program Files\java\jre6\lib\javaws.jar"
-Dkernel.debug=true -Dkernel.background.download=false com.sun.javaws.Main -shortcut -uninstall 

works.

But both command works in a normal jre.
Comments
EVALUATION Correction: it actually has to do with a JAR being improperly added to the bootclasspath. The full sequence of events is: 1) deploy.jar and javaws.jar are manually added to the classpath via the command line args. deploy.jar is part of the core, javaws.jar is not. 2) We attempt to load a class out of javaws.jar. 3) The classloader can't find it and delegates to Kernel. 4) Kernel downloads the jar and adds it to the boot class path. 5) The system class loader successfully loads the class. 6) The javaws.jar class now tries to load a deploy.jar class. 7) ...but since bootclasspath classes can't see standard classpath classes, we now get a NoClassDefFoundError So the root problem is step 4: we improperly added javaws.jar to the boot class path. javaws.jar and deploy.jar, with possibly a couple of others, are special cases that are not normally part of the boot class path. The reason that this was working previously was that deploy.jar was ALSO being added to the boot class path, so they were both in the same search list. Due to the nature of Kernel's interactions with the classloader and VM, the JAR file will have to be downloaded prior to letting the context classloader search for it. We do not need to add the JAR to the classpath ourselves -- it's either already on the classpath, in which case the subsequent search will find it, or it hasn't been added to the classpath, in which case it won't hurt to prematurely download it (we need to anyway) but the subsequent search should be allowed to fail with its natural ClassNotFoundException.
03-03-2008
EVALUATION The root problem is that deploy.jar didn't exist when the classloader first looked for it, and it never checks again. In the old system, it worked fine anyway because we would manually add (another) entry for deploy.jar and tell the VM to check again. In the new system, we realize "hey this is already present" and bail immediately. We never add a new entry for it to the classpath or cause another search. Shouldn't be too hard to fix.
25-02-2008