hg: jigsaw/jigsaw/hotspot: Summary: Allow passing in a non-null module loader to translate to boot loader.
mandy.chung at oracle.com
Wed May 23 17:59:22 PDT 2012
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
> 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
More information about the jigsaw-dev