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

Rémi Forax forax at univ-mlv.fr
Fri Aug 24 10:25:42 UTC 2012


I also vote for adding this overload, a lot of the usage of 
Class.forName with three parameters are in fact just a way to load a 
class without initialize it.

Rémi

On 08/24/2012 07:21 AM, serguei.spitsyn at oracle.com wrote:
> 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.
>>>
>




More information about the core-libs-dev mailing list