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

[Mandy Chung]

  On 5/23/2012 9:51 AM, David M. Lloyd wrote:
>
> 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?

FWIW, the base module class loader does delegate to VM null loader in 
the implementation.

In classpath mode, Class.forName() with a null class loader argument 
will load classes from the bootclasspath.   In module mode, when 
Class.forName() with a null loader is called,  do you expect it loads 
classes only in the base module or all classes from all jdk modules?

> 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.
>

In classpath mode, existing application and class loaders should work as 
it is today.  The platform modularization should be transparent to the 
classpath mode applications/class loader.

In module mode,  a relevant question is what module do classes loaded by 
the non-module
class loader belong to?  What types are visible to that non-module class 
loader?

One initial proposal is to have classes loaded by a non-module class 
loader belong to the module in which that class loader is created.   
Therefore, all types visible to the module will also be visible to that 
non-module class loader.  Details are yet to be fleshed out and prototyped.

Mandy