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

[Vitaly Davidovich]

Hi Paul,

That flag is an action, as you state.  Basically means whether static
initialization should be performed.

Vitaly

Sent from my phone
On May 9, 2012 11:43 AM, "Paul Sandoz" <paul.sandoz at oracle.com> wrote:

> 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
>
>