Legacy mode, module mode, mixed mode

[Mandy Chung]

On 06/03/10 05:09, Alan Bateman wrote:
> Mandy - this is good informative write-up. A couple of comments inlined.
>
>
> Mandy Chung wrote:
>> :
>>
>> 0. Module Images
>>
>>   A module image consists of the jdk base module and a set of platform
>>   modules.  The jdk modules are installed in the system module
>>   library ($JAVA_HOME/lib/modules).
>>
>>   jre-module-image is the full JRE (equivalent the legacy j2re-image).
>>   The "jdk.jre" module is the aggregator module representing the entire
>>   JRE.
>>
>>   jdk-module-image is the full JDK (equivalent to the legacy 
>> j2sdk-image).
>>   The "jdk" module is the aggregator module representing the entire JDK.
>>
>>   rt.jar, tools.jar and other jar files no longer exist in the module
>>   image.
> Should this section include a few words to make it clear that the 
> directory/file layout for the jdk-module-image is the same as the 
> jre-module-image? Just thinking we should make it very obvious to the 
> reader that the jdk image doesn't have the runtime in a "jre" 
> directory as before.
>

Good point.

I think this deserves to have its separate document about details of the 
module images including the layout.   We can use this note as the 
starting point.

>>
>> :
>>
>>   In the legacy mode, the system classes are loaded from the platform
>>   modules installed in the system module library whereas non-system
>>   classes are loaded from classpath, extension mechanism or custom
>>   class loader as it is today.
> Should this paragraph make it clear that the "non-platform" modules 
> are ignored (and perhaps reference the migration/mixed-mode support in 
> section C).
>

Okay.

>>
>>
>> :
>>
>> B) Legacy mode
>>
>>   There are various ways to alter the bootclasspath that will continue
>>   to work in legacy mode:
>>
>>   1. -Xbootclasspath/p to prepend bootclasspath
>>   2. Endorsed directory to prepend the default bootclasspath
>>      via -Djava.endorsed.dirs (one or more directories) and
>>      the default $JAVA_HOME/lib/endorsed directory
>>   3. -Xbootclasspath/a to append bootclasspath
>>   4. JVMTI and java.lang.instrument to append the bootclasspath
> Should this section mention the extensions mechanism (ext directory 
> where provider implementations and other JAR files are often copied 
> into)?

Good suggestion.  It's useful to include a section describing the 
extension mechanism in this note.  The extension mechanism doesn't 
extend the bootclasspath and therefore it's not in the above list.
>
>> :
>>
>> A) Module mode
>>
>> 1. Current implementation
>>
>>   - The module boot path is passed by the java launcher as a
>>     "sun.java.launcher.module.boot" system property and the
>>     VM will find the primordial classes from that path.
> Will this be a problem for custom launchers, folks using the JNI 
> invocation API, etc?

Ah...I forgot to mention this.  This will be removed when the VM 
interfaces with jigsaw to find the boot module.

Thanks for the comment.
Mandy