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

[serguei.spitsyn at oracle.com]

I was thinking about the same.
But a CCC request is needed for such a change in public API.
It can be done separately if any other API changes are necessary.

Thanks,
Serguei


On 8/23/12 6:27 PM, David Holmes wrote:
> 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 
> Class.forName():
>
> public static Class<?> forName(String name, boolean initialize)
>
> That way the loader argument could be dropped completely from a number 
> of the use-cases.
>
> David
>
> 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:
>> http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7193339/webrev.00/
>>
>> 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 java.lang.management.
>>