United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6667564 bootclasspath/classpath search problem
JDK-6667564 : bootclasspath/classpath search problem

Details
Type:
Bug
Submit Date:
2008-02-25
Status:
Closed
Updated Date:
2010-09-08
Project Name:
JDK
Resolved Date:
2008-05-12
Component:
deploy
OS:
windows
Sub-Component:
deployment_toolkit
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10
Fixed Versions:
6u10 (b21)

Related Reports

Sub Tasks

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

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.
                                     
2008-02-25
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.
                                     
2008-03-03



Hardware and Software, Engineered to Work Together