Review Request: 7193339 Prepare system classes be defined by a non-null module loader

David Holmes david.holmes at
Fri Aug 24 01:27:01 UTC 2012

Hi Mandy,

While I understand what you are doing and that it "works" it is far from 
obvious upon code inspection that where you replace null with 
Foo.class.getClassLoader(), that the result would always be null.

Another way to simplify this would be to add a new overload of 

public static Class<?> forName(String name, boolean initialize)

That way the loader argument could be dropped completely from a number 
of the use-cases.


On 24/08/2012 3:43 AM, Mandy Chung wrote:
> This change is to bring the jdk modularization changes from jigsaw repo [1]
> to jdk8. This allows the jdk modularization changes to be exposed for
> testing as early as possible and minimize the amount of changes carried
> in the jigsaw repo that helps sync up jigsaw with jdk8/jdk9.
> Webrev at:
> Summary:
> The VM bootstrap class loader (null) has been the defining class loader
> for all system classes (i.e. rt.jar and any classes on the bootclasspath).
> In modular world, the system classes are going to be modularized into
> multiple modulesand and many of which will be loaded by its own
> (non-null) module loader.
> The JDK implementation has the assumption that the defining class loader
> of system classes is null and it'll no longer be true when running as
> modules. Typical patterns in the JDK code include:
> Class.forName(classname, false, null) should be changed to:
> Class.forName(classname, false,<loader of the current class>)
> if (loader == null) condition check should be modified to check if the
> loader
> is responsible for loading system classes.
> This is the first set of change for this problem we identified. Similar
> change in other components will be made in the future.
> Testing: run all jdk core test targets on all platforms.
> Thanks
> Mandy
> P.S. I'm cc'ing servicebility-dev as this patch modifies 2 files in
> the

More information about the core-libs-dev mailing list