-
Bug
-
Resolution: Fixed
-
P4
-
7
-
b03
-
generic
-
generic
-
Verified
This is a bug about the behavior of the system class loader regarding the treatment of empty elements on the bootclasspath. Empty elements are ignored when loading classes, but are not ignored when looking for resources.
Attached is a shell script which demonstrates the bug.
The shell script creates two copies of a small test program and puts them in two sibling directories. The only difference between these copies is each knows which directory it is in.
The test program is then run with a variety of bootclasspaths. Most of the test runs behave as expected, and serve to verify the basic behavior of the test progam and the paths.
However, the final two test cases set up a bootclasspath with an empty element in it, and with one copy of the test in it, while the current directory is set to the directory containing the other copy of the test.
The test that the class for the test comes from one directory, but the resource for the class for the test comes from the other directory. In other words, the empty element on the bootclasspath is ignored when finding classes, but is not ignored when finding resources.
This behavior is inconsistent and should be fixed. It would be preferable for empty elements on the path to be ignored for resources as well as classes. It would be useful to be able to construct paths like ${a}:${b} and not have to worry if the variables are empty. This general issue causes problems for the JDK tools like javac and apt, which use the JDK service locater mechanism to locate services described in resource files.
For reference, here is the output from the test script, illustrating the failure.
This class: a/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/a/Test.class
Test OK
This class: b/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/b/Test.class
Test OK
This class: a/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/a/Test.class
Test OK
This class: b/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/b/Test.class
Test OK
This class: a/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/a/Test.class
Test OK
This class: b/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/b/Test.class
Test OK
This class: b/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/b/Test.class
Test OK
This class: a/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/a/Test.class
Test OK
This class: b/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/a/Test.class
Test FAILED
This class: a/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/b/Test.class
Test FAILED
Attached is a shell script which demonstrates the bug.
The shell script creates two copies of a small test program and puts them in two sibling directories. The only difference between these copies is each knows which directory it is in.
The test program is then run with a variety of bootclasspaths. Most of the test runs behave as expected, and serve to verify the basic behavior of the test progam and the paths.
However, the final two test cases set up a bootclasspath with an empty element in it, and with one copy of the test in it, while the current directory is set to the directory containing the other copy of the test.
The test that the class for the test comes from one directory, but the resource for the class for the test comes from the other directory. In other words, the empty element on the bootclasspath is ignored when finding classes, but is not ignored when finding resources.
This behavior is inconsistent and should be fixed. It would be preferable for empty elements on the path to be ignored for resources as well as classes. It would be useful to be able to construct paths like ${a}:${b} and not have to worry if the variables are empty. This general issue causes problems for the JDK tools like javac and apt, which use the JDK service locater mechanism to locate services described in resource files.
For reference, here is the output from the test script, illustrating the failure.
This class: a/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/a/Test.class
Test OK
This class: b/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/b/Test.class
Test OK
This class: a/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/a/Test.class
Test OK
This class: b/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/b/Test.class
Test OK
This class: a/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/a/Test.class
Test OK
This class: b/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/b/Test.class
Test OK
This class: b/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/b/Test.class
Test OK
This class: a/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/a/Test.class
Test OK
This class: b/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/a/Test.class
Test FAILED
This class: a/Test.class
This class as resource: file:/w/jjg/work/jvm_getResource_bug/b/Test.class
Test FAILED
- relates to
-
JDK-8185541 Add back test cases for resource lookup from bootclasspath
-
- Resolved
-
-
JDK-6760805 empty element on bootclasspath breaks test/tools/apt/Compile/compile.sh
-
- Closed
-
-
JDK-6760930 empty element on bootclasspath breaks test/tools/apt/Discovery/discovery.sh
-
- Closed
-