Bug in ClassPathContext?

[Mandy Chung]

Sorry for the delay in getting back to this (distracted and working
on another bug).

On 10/10/2012 4:38 PM, mark.reinhold at oracle.com wrote:

> 2012/10/10 15:53 -0700, mandy.chung at oracle.com:
>> You're right - the last statement doesn't match the comment. I haven't
>> been able to understand why the unit tests have been passing
>> with jdk-module-image (no $BUILD/classes directory and also JPRT build)
>> in my testing before the push. Hmm.. all modules are loaded by the
>> bootstrap null loader except and so that works.
> Now that I've studied your recent URLClassPath changes, I think what's
> happening is that if a $BUILD/classes directory doesn't exist then the
> tools and ext modules are marked as bootstrap modules, so they're loaded
> by the bootstrap loader rather than a URLClassPath.ModuleLibraryLoader
> as you probably intended.

No that's not my intent.  If there is no $BUILD/classes directory
(not a development build), tools/ext modules should not be loaded by
the bootstrap loader.

The comment is correct and the check should be (in both toolsModule()
and extModules() methods):

-        return file("classes") != null ? modules : new String[0];
+        return file("classes") == null ? modules : new String[0];

This tries to retain the classpath mode behavior as with a legacy
development build.  In a legacy jdk build, all classes including tools
are loaded by the bootstrap loader.  Perhaps this isn't highly
necessary with module library.

The module-info for jdk.classpath requires all jdk modules and
thus we need to filter out the tools/ext modules from the list
to be loaded by the bootstrap loader during system initialization.
See the comment in ClassPathContext.loadClassPathConfiguration method
What I don't yet understand is why things don't work in development mode,
when these modules aren't marked as bootstrap and so should be loaded by
an appropriate ModuleLibraryLoader.

URLClassPath.ModuleLibraryLoader is only used by non-bootstrap loaders
(i.e. system and extension class loader) and also used to search
resource files from the bootclasspath.


>> Are the unit tests failing with jigsaw/jigsaw tip?
> Yes:
>
>    test/org/openjdk/jigsaw/cli/SignedModuleFileTest.sh
>    test/org/openjdk/jigsaw/classpath/classpath.sh
>    test/org/openjdk/jigsaw/hello-native.sh

Sorry for missing this.  I validated my patch with the development build
and jdk-module-image.  I will wait for the JPRT job to finish before I
push the changeset.

Mandy