Platform module for javac to locate classes from system module library

[Jonathan Gibbons]

Mandy,

I like the suggestion of using a module name such as jre.legacy for the 
situations like 3.a.ii when we are compiling legacy code with no 
module-info at all. (I'm not fussed about the exact name that you 
choose.) and when some sort of module resolver is in use.

I have a mild preference for sun.boot.class.path remaining available for 
"no modules" mode (2d), but the more we exercise and  use the preferred 
alternatives, the less important it becomes to have a fall back 
position, which is what -XDnomodules provides.

-- Jon


Mandy Chung wrote:
> 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 
>