Platform module for javac to locate classes from system module library

[Mandy Chung]

Jon, Mark,

There are two module compilation modes described in [1]:
   3.a) Single module mode
          3.a.i - compiling modular code (i.e. module-info.java exists)
          3.a.ii - compiling non-modular code (i.e. no module-info.java 
exists)
   3.b) Multi-module mode

In this context, I'm interested in the jigsaw mode (2.a) that asks the 
jigsaw resolver for module resolution and the system module library 
contains some platform modules.

For compiling modular code (single (3.a.i) or multiple (3.b) module 
mode), there is one or more module-info.java files on the command line.  
If the module-info.java doesn't specify a dependency on the platform 
modules, javac will use the default platform module to locate classes 
and resolve dependencies.   This sounds good so far (what the default 
platform module should be is a separate question).

When compiling non-modular code in single module mode (3.a.ii)), there 
is no module-info.java file explicitly specified on the command line and 
javac will need to read module-info from the system module library.   
I'd like this module resolution mode to provide equivalent functionality 
as "javac's legacy mode" such that it can locate all classes in the 
system module library regardless of what modules are installed (i.e. the 
default platform module might not exist).   For example, jdk-base-image 
only contains jdk.base module + jdk.logging + javac and its 
dependences.  I expect it can compile a simple program that uses 
java.util.logging API:
  $ cat Helloworld.java
     public class Helloworld {
          java.util.logging.Logger.getLogger("org.hello");
     }

  $ jdk-base-image/bin/javac Helloworld.java

In this case, the default platform module doesn't exist.  Additional 
modules can be installed in the system module library later.  Should 
this module resolution mode (3.a.ii) support a system module library of 
any installed module?  Or should this module resolution mode (3.a.ii) 
only be supported in the full jdk (i.e. equivalent to the legacy image)?

To support (3.a.ii) in a system module library of any installed module, 
one proposal is to have javac to use a module that can aggregate all 
modules installed in the system module library at any point in time for 
resolution instead of the default platform module.  For example, we can 
define a "jre.legacy" module that has optional dependences on all jre
modules and the jre.legacy is always installed in the base image.  This 
is described in the legacy boot loader approach [2].  For (3.a.i) mode, 
javac will use the default platform module.  For (3.a.ii) mode, javac 
will use the "jre.legacy" module.   Jon also explores the option of 
setting 'sun.boot.class.path" property.  I don't think we should rely on 
the existence of "sun.boot.class.path" property in the modular world.

Thanks
Mandy

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-April/000763.html
[2] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-February/000563.html