Bug in ClassPathContext?

[mark.reinhold at oracle.com]

2012/10/10 20:13 -0700, mandy.chung at oracle.com:
> On 10/10/2012 4:38 PM, mark.reinhold at oracle.com wrote:
>> 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.

In the legacy build it was an expedient hack to load tool classes via the
bootstrap class loader in a development build.  I don't see any reason to
preserve that behavior, especially when we now have a chance to reduce
the difference between development and image builds.

FYI, I tried changing the lines in question to return the array of module
names unconditionally, but that didn't work.  Haven't yet figured out why.

- Mark