JDK support for VM to read classes from modules in a module library

[Paul Sandoz]

Hi Mandy,

Regarding the change to com/sun/jmx/mbeanserver/MXBeanMapping.java:

 172             return Class.forName(className, false, MXBeanMapping.class.getClassLoader());

Do you think it would make sense to add the following method to Class:

  public static Class<?> forName(String className, boolean initialize) {
    return forName0(className, initialize, ClassLoader.getCallerClassLoader());
  }

there by removing the explicit reference to the class loader in MXBeanMapping.java. It intuitively feels like a best practice to reduce the cases of explicitly dealing with a class loader.



The change to java/lang/management/PlatformComponent.java from:

 366                        Class.forName(mxbeanInterfaceName, false, null);

to:

 367                        Class.forName(mxbeanInterfaceName);

changes the initialization [*] flag from false to true. Is that intended?

Paul.

[*] i must admit to never quite understanding what this flag means.
Java doc states that for initialize parameter "whether the class must be initialized". Is that a constraint or an action? I presume the later.


On May 5, 2012, at 8:38 AM, Mandy Chung wrote:

> Karen and I have been working on implementing the support in the VM and library to read classes from a module library in native and proper system initialization for modules.  This will replace the current workaround of using bootclasspath in module mode.  I have put together a set of slides [1] to give an overview of this work (thanks to Alex, Karen, and Alan for their feedback and improvements).
> 
> This work includes several pieces:
> 1) Jigsaw native library interface that the VM will use to search and read classes from the base module
> 
> This replaces the existing mechanism in the VM that searches and reads classes from rt.jar and the default bootclasspath (that no longer exists in modular JDK) for loading bootstrap classes.
> 
> Webrev for the jdk change:
>   http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-jigsaw-ms/
> 
> Karen will send out the webrev for the VM change separately.
> 
> The jigsaw native library interface is defined in jigsaw.h and its implementation is in jigsaw.c.  The temporary hack in org.openjdk.jigsaw.BootLoader to extend the bootclasspath for the base and other modules is now removed.  I have added a few static methods in the Platform class for the system to determine if it's running in module mode, if a given class loader defines system classes, and to get the base module loader (refer below for details).
> 
> This webrev also includes some minor cleanup in the modularization such as fixing the jdk.desktop requires optional jdk.jaxp that should not be an optional dependency and moving java.text.Bidi class to the base module (Alan has eliminated the bidi to desktop dependency a while ago).
> 
> 2) system modules to be granted with AllPermissions
> 
> Today the classes on bootclasspath are granted with AllPermissions.  In a modular JDK, we need to a way to determine if it's a system module and grants with AllPermission.  Alan has implemented the module URL as the code source to modules and grants all permissions to jdk.* modules, as an interim solution.   Sean is looking into different options and a reliable way to identify a system module.
> 
> Webrev at:
>   http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-module-url/
> 
> 3) The JDK code needs to be audit for the use of class loader and update for modules as listed in the open issues.  We have made changes in a few places in the JDK to fix some of the low hanging fruits that get more of the existing tests to pass when running as modules.
> 
> a. bootstrap classes skip permission check e.g. ClassLoader.getClassLoader()
> 
> Today bootstrap classes are loaded by null loader.  In module mode, system modules are loaded by non-null module loader.    A method Platform.isPlatformLoader(ClassLoader) is added to replace the "cl == null" check.  Note that these methods may be more appropriate to live in java.lang or some other class but I add it in Platform class for now.
> 
> b. Platform.getBaseModuleLoader() - the base module loader is needed when the library
> code wants to load a class in base's optional dependency (e.g XML) because Class.getClassLoader() currently returns null (see the open issue listed in [1]).
> 
> c. replace classloader parameter in the Class.forName call from null to an appropriate loader when loading a class that is not in the base module (e.g. management, scripting, etc).
> 
> Webrev:
>   http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-class-loader-fix/
> 
> There will be more of this kind of changes required in the jdk and this is just to set a few examples to get going.
> 
> You can also look at all changes together in this webrev:
>   http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-class-loading/webrev-all/
> 
> Thanks
> Mandy
> [1] http://openjdk.java.net/projects/jigsaw/doc/module-class-loading.pdf