hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader.

[David Holmes]

On 24/05/2012 2:51 AM, David M. Lloyd wrote:
> On 05/22/2012 07:48 PM, karen.kinnear at oracle.com wrote:
>> Changeset: c51a2d4dada0
>> Author: acorn
>> Date: 2012-05-18 13:34 -0400
>> URL: http://hg.openjdk.java.net/jigsaw/jigsaw/hotspot/rev/c51a2d4dada0
>>
>> Summary: Allow passing in a non-null module loader to translate to
>> boot loader.
>> Reviewed-by: mchung
>>
>> ! make/linux/makefiles/mapfile-vers-debug
>> ! make/linux/makefiles/mapfile-vers-product
>> ! make/solaris/makefiles/mapfile-vers
>> ! src/share/vm/prims/jni.cpp
>> ! src/share/vm/prims/jvm.cpp
>> ! src/share/vm/prims/jvm.h
>
> This change seems to me the wrong way around: since using null as an
> argument to Class.forName() (and similar) still has to be supported, why
> not simply have the base module class loader delegate to its parent?
> This, in combination with "spoofing" the base module's
> Class.getClassLoader() output, seems like it would suffice.
>
> On a related note, most standalone class loaders out in the wild will in
> fact delegate to their parent. What does this mean when classes that
> were a part of the core JDK are now in discrete (non-visible) modules? I
> think this is a major weakness of retroactively modularizing the core.

I'm still trying to see how things connect but assuming legacy mode I 
assume there will be something equivalent of the current "system 
classloader" and I would expect it to have a parent that is the base 
module loader, and the base module loader knows how to use the module 
system to find the right module loader for a given class.

Is that a reasonable picture? If not what is the actual picture?

David Holmes