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

[Mandy Chung]

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