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.
