Legacy Boot Loader Approach

[Mark Reinhold]

> Date: Wed, 24 Feb 2010 00:42:05 -0800
> From: mandy.chung at sun.com

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

Yes, it's a good start.  A few questions though ...

When in legacy mode, do the platform classes appear to be in the
"bootstrap" class loader?  That is, does the getClassLoader() method
of such classes return null, even though the classes don't come from
the VM's built-in loader?

Will it be a problem that the legacy loader and the Jigsaw loader for
the jdk.legacy module are different?  With two loaders the initiating
and defining loaders for platform classes will be different, which
could be a compatibility issue.

In legacy mode do the extension and "endorsed standards" mechanisms
still work as they do today?

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

Good!

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

Agreed.  If it's not too hard to support jar-file-packaged agents in
non-legacy mode then we should do that.

- Mark