Legacy mode to find modules for tools.jar (or other jars not in the bootclasspath)

[Mandy Chung]

Latest webrev:
   http://cr.openjdk.java.net/~mchung/jigsaw/legacy-mode/webrev.01/

I'm happy that the legacy mode support now passes the 
SKIP_BOOT_CYCLE=false build and it gets rid of the java launcher 
bootclasspath hack.

It also includes the mixed mode support that needs  further testing.

Mandy

On 06/03/10 11:50, Mandy Chung wrote:
> I finally get a chance to revise the legacy mode support (III.B.2 as 
> described in [1]) and add the mixed mode legacy application support 
> (III.C.a as in [1]).  I wanted to do more extensive testing before 
> requesting a formal code review (the testing I have done so far is 
> good).  I'm not surprised if I have some strange unexpected issues.
>
> This webrev will give you a better idea how this works as described in 
> [1].
>     http://cr.openjdk.java.net/~mchung/jigsaw/legacy-mode/webrev.00/
>
> I'd like to start one discussion in this thread:
>
> With the tradition legacy image, to compile and run with classes from 
> tools.jar (or other JDK jars that are not part of the default 
> bootclasspath), the -classpath option is required to add it to the 
> classpath.
>
> With the new module image, the question is: how should the legacy 
> application find the jdk modules corresponding to tools.jar and other 
> jars?  See LegacyLauncher.java line 142.
>
> I considered 3 options and propose to use (3a):
> 1) Default is "jdk.jre" (i.e. entire JRE - see section 0 in [1])
> 2) Default is "jdk" (i.e. entire JDK including tools.jar and other)
> 3) Default is "jdk.legacy" that is an aggregator module that 
> optionally requires all jdk modules.
>   a) install jdk.legacy in jre-module-image and jdk-module-image (i.e. 
> legacy mode is only supported in jre-module-image and jdk-module-image.)
>   b) install jdk.legacy with the base image (i.e. legacy mode is 
> supported in any module image provided that the classes the app 
> depends on exist)
>
> 1) Default is "jdk.jre"
> We could extend this to check if $JAVA_HOME/lib/tools.jar is added in 
> the classpath; if so, it will use "jdk" module.
>
> Pros:
> - No change is required in the command to compile or run java application
> - Legacy applications will run on jre-module-image or jdk-module-image
> Cons:
> - Require to continue to use -cp tools.jar even if tools.jar doesn't 
> exist in the module image
> - Legacy applications will not run on jre-base-image (or with some 
> other modules installed)
>
> (2) Default is "jdk"
>
> Pros:
> - No change in the command to compile or run java application
> Cons:
> - Legacy app must run on jdk-module-image (not jre-module-image in 
> which "jdk" module is not installed)
>
> (3) Default is "jdk.legacy" (or call it "jdk.any")
>
> Pros:
> - No change is required in the command to compile or run java application
> - Legacy apps will run on jre-module-image or jdk-module-image
> Cons:
> - One additional aggregator module
>
> Comment, thoughts?
>
> Mandy
>
> [1] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-June/001039.html
> [2] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-February/000563.html 
>