Legacy Boot Loader Approach

[Mandy Chung]

On 02/25/10 08:43, Mark Reinhold wrote:
>> 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?

All platform classes are defined by the bootstrap class loader (null 
loader).
and yes, the getClassLoader() method of such classes returns null.

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

A good point.  The JVM spec section 5.3 [1] states this:
      If D was defined by the bootstrap class loader, then the bootstrap
      class loader initiates loading of C (§5.3.1).

In other word, the initiating loader of a platform class is always null
regardless of which loader initiates the loading.

Karen, can you confirm if this is true?

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

Yes, they works as they do today.

The extension class loader implementation is not changed except
its parent is now the legacy loader (instead of null).  If an existing
application depends on the application/extension class loader
delegation hierachy (that's the internal implementation), it will
be broken.  An example is java.util.ServiceLoader that I have
fixed.

As for the endorsed standards mechanisms, this is covered
in the same way as the non-default bootclasspath since the VM
is the one processing the value set in -Djava.endorsed.dirs
property that gets expanded in the bootclasspath.

Your question prompts me to doublecheck the order of the
bootclasspath constructed from various VM options:
    -Xbootclasspath/p
    -Djava.endorsed.dirs
    default bootclasspath (or -Xbootclasspath)
    -Xbootclasspath/a

Sigh... if a platform class of different version is put in the 
java.endorsed.dirs,
that version should be loaded instead of the one from the system module
library.   I need to come up with a solution to handle this ordering
correctly.

Mandy
[1] 
http://java.sun.com/docs/books/jvms/second_edition/html/ConstantPool.doc.html#72007