Legacy Boot Loader Approach

[Mandy Chung]

Mark,

I have implemented the legacy mode support that we discussed about.
The approach is to create a legacy boot loader that delegates to
the jigsaw module loader responsible for loading classes from the
platform context that is stored in the configuration of a special
jdk.legacy module.

The platform context has to include the jdk modules that are
currently  installed in the system module library. As modules 
can be installed/uninstalled any time, to handle that, I create
a jdk.legacy module that has optional dependences on all jdk 
modules and the jdk.legacy is always installed in the base
image.  When a jdk module is installed, the configuration of
the jdk.legacy module will be recomputed and the newly installed
module will be included in the platform context during class
loading.  The jdk.legacy module avoids computing the platform
context at startup time.

Does this approach sound reasonable?

The legacy boot loader also has to delegate to the VM to find
if there is any class in the bootclasspath but not in the platform
context (e.g. non-default bootclasspath set by -Xbootclasspath or
-javaagent VM options or 
java.lang.instrument.Instrumentation.appendToBootstrapClassLoaderSearch
[1]).
So the existing mechanism to alter bootclasspath will continue
to work in legacy mode.


Webrev at:
   http://cr.openjdk.java.net/~mchung/jigsaw/legacy-bootloader-webrev/

A side note:
Java agents are deployed in jarfile to pass to the -javaagent
VM option, java.lang.instrument API and com.sun.tools.attach API.

This needs further investigation to determine if we can keep 
these APIs only for legacy application use and define new API
for module mode use.

Mandy 
[1] http://download.java.net/jdk7/docs/api/java/lang/instrument/Instrumentation.html#appendToBootstrapClassLoaderSearch(java.util.jar.JarFile)