Legacy mode, module mode, mixed mode
Alan.Bateman at oracle.com
Thu Jun 3 05:09:01 PDT 2010
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
> jdk-module-image is the full JDK (equivalent to the legacy
> 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
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
> 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
> 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)?
> 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?
More information about the jigsaw-dev