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

serguei.spitsyn at serguei.spitsyn at
Thu Aug 23 19:48:11 UTC 2012


It looks good.
Just a question below.

|| *src/share/classes/java/lang/management/*

596             String intfName = mxbeanInterface.getName();
599                     " is not an instance of " + mxbeanInterface);

Did you want this?:
596             String intfName = cls.getName();
599                     " is not an instance of " + cls);


On 8/23/12 10: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