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

Paul Sandoz paul.sandoz at
Mon Aug 27 08:40:52 UTC 2012

On Aug 25, 2012, at 12:57 AM, Mandy Chung <mandy.chung at> wrote:

> On 8/24/2012 3:44 PM, David Holmes wrote:
>> My other query with these changes is whether we are certain that using the specified loader rather than the boot loader will always be correct. 
> Yes I'm to my best knowledge but I'm looking to the reviewers to tell me otherwise :)

To the best of my knowledge too.

> The class being loaded is either part of the same module or expressed in its module dependency.  

And for that reason it may be best to use the three arg method call [*] as much as possible for code in the JDK code base. If code is shuffled around it then becomes clearer if the constraint, "either part of the same module or expressed in its module dependency", breaks.


[*] That is not a negative on the stuff below.

> I ran the JCK tests in module mode with the jigsaw modular JDK that uncovered these files to be changed.  There are other places in the JDK that I didn't touch since they were not found by my testing.
> BTW, I have created a new CR:
>   7194006:  A new Class.forName(String cn, boolean initialize) method
> This include Paul's suggestion and slightly improved the javadoc
> for Class.forName you suggested [1]:
> -     * @param initialize whether the class must be initialized
> +     * @param initialize if {@code true} the class will be initialized.
> +     *                   See Section 12 of <em>The Java Language Specification</em>.
> Thanks
> Mandy
> [1]

More information about the core-libs-dev mailing list