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

[Mandy Chung]

On 5/23/2012 4:12 PM, David Holmes wrote:
> 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.
>

We now refer "legacy mode" to as "classpath" mode (thanks to Serguei for 
the better name).  "legacy" may be interpreted as obsolete and not 
supported which is not our intent.

In classpath mode, the bootstrap classes will continue to be loaded by 
the null loader for compatibility reason.  So it will load all classes 
from base, desktop, jaxp, corba, rmi modules etc (not only the base 
module).    Essentially all modules that constitute the rt.jar and 
classes on the bootclasspath.

In module mode, the base module loader plays an important role to find 
the right module loader for a given class in another module.   In 
classpath mode, it isn't the case.  My view is that it no longer needs 
the base module loader for class loading but we may still need it for 
getting resources.

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

I think your question is specifically for classpath mode.  My current 
view is that it will continue to have the bootstrap null loader, 
extension class loader, and system class loader finding and defining the 
same set of classes as it is today.   There are still module loaders 
created for the jdk modules but the  extension class loader and system 
class loader will delegate to the right module loader to find a class in 
the ext directory and classpath.   The module loaders for the bootstrap 
classes are only used to lookup anything other than classes.  Karen and 
I are working on a prototype to find out if there is any issue with this 
approach.

Mandy