Jigsaw classpath mode support

[Mandy Chung]

Updated webrev at:
    http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/classpath-mode.01/

I have modified org.openjdk.jigsaw.ClassPathContext and 
sun.misc.Launcher classes to incorporate the comments Alan, Paul and 
Karen have.  Also updated the ModulesProblemList.txt to include a few 
known failures that will be looked into next.

Mandy

On 8/7/2012 10:47 AM, Mandy Chung wrote:
> I have implemented the "classpath mode" support running on
> a module image.
>
> Webrev:
>   http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/classpath-mode.00/
>
> JDK has been modularized in the jigsaw repo.  There no longer
> has a rt.jar, tools.jar, or any jar file.  The system classes
> are now installed in a system module library as modules. This
> change will allow the bootstrap class loader, extension class
> loader, and system class loader to search classes and resources
> in the system module library as the default.  Some implementation
> details:
>
> 1. VM used to maintain the default bootclasspath list and search
> classes in it.  Now it will call jigsaw native interface to find
> classes from the module library unless -Xbootclasspath is set
> to override the default bootclasspath.  The -Xbootclasspath/p
> and -Xbootclasspath/a will continue to work as it is today.
>
> Karen will be sending out the webrev for the hotspot change
> separately.
>
> 2. tools.jar
>
> For compatibility, -classpath tools.jar should continue
> to work. There are existing applications using URLClassLoader
> that loads classes from tools.jar (e.g. test harness) that
> also should continue to work.
>
> To be able to determine if the path of the given tools.jar
> to either -classpath option or URL parameter to URLClassLoader
> is the same path as JAVA_HOME/lib/tools.jar in a lightweight,
> the module image for the full JDK will contain an empty tools.jar.
> This also allows applications that check for the existence of
> tools.jar to continue to work.
>
> sun.misc.URLClassPath is the main implementation class to
> support URLClassLoader to search a file from the given URLs.
> Both ExtClassLoader and AppClassLoader are URLClassLoader.
> URLClassPath is extended to find resource file from the
> appropriate system modules if the given URL is
> JAVA_HOME/lib/tools.jar or JAVA_HOME/lib/ext.
>
> 3. How to determine which modules belong to bootclasspath,
> ext directory, and tools.jar (and a few jar files in JDK/lib)
> at runtime
>
> A configuration for the classpath mode support is loaded at
> startup rather than generated to minimize the startup cost.
> The idea is to have one ClassPathContext for bootclasspath,
> one for extension and one for the jdk tools.
>
> In this prototype, I just define a new module "jdk.classpath"
> and install it in the module image.  It hardcodes the list
> of modules for each ClassPathContext for now.  One alternative
> is to extend jpkg to generate "jdk.classpath" config specifically
> for this classpath mode.  We'll explore this later.  But I
> think this is good enough for now.
>
> 4. I made simple change in StoredConfiguration to reduce
> the footprint of the configuration stored on disk. There
> were several regression tests setting -Xmx failed due to
> the increase of the startup footprint without this change.
>
> With storing the context names and package names only once,
> it reduces the size of the config with 35-40%.  I suspect
> the fast configuration will make similar change.
>
> $ du -k `find . -name 'config'`
> 696     ./jdk.corba/8-ea/config
> 1304    ./jdk.classpath/8-ea/config
> 1232    ./jdk.tools/8-ea/config
> 604     ./jdk.rmi/8-ea/config
> 680     ./jdk.tools.base/8-ea/config
> 604     ./jdk.base/8-ea/config
> 1056    ./jdk.tools.jaxws/8-ea/config
> 676     ./jdk.devtools/8-ea/config
> 608     ./jdk.tools.jre/8-ea/config
>
> $ du -k `find . -name 'config'`
> 444     ./jdk.corba/8-ea/config
> 792     ./jdk.classpath/8-ea/config
> 748     ./jdk.tools/8-ea/config
> 392     ./jdk.rmi/8-ea/config
> 436     ./jdk.tools.base/8-ea/config
> 392     ./jdk.base/8-ea/config
> 636     ./jdk.tools.jaxws/8-ea/config
> 436     ./jdk.devtools/8-ea/config
> 396     ./jdk.tools.jre/8-ea/config
>
>
> 5. I ran the jtreg regression tests and JCK api&  lang tests.
> The test results are looking real good.   Compared with the
> jigsaw repo as the baseline, there are 2 new JCK test failures
> that I have to investigate (passed: 23,685; failed: 138; error: 28)
>
> There is a startup initialization issue due to the use of
> Files.isSameFile method and the default file system provider
> is replaced with user defined one.  I'm currently looking into
> a fix for it.
>
> I'd like to get this webrev out for review early and I also
> expect any issue found will be minor that I will generate a
> separate patch on top of this as a separate review.
>
> Open Issues:
> 1. sun.boot.class.path no longer represents the search path
> for the bootstrap class loader.  Any application depending
> on this system property may be impacted.
>
> rmic is one example that uses this property value to find
> system classes.  There has been work to convert rmic to
> use the javax.tool APIs that will support a module image.
> Unless rmic becomes module-aware, it continues to use
> the launcher hack setting -Xbootclasspath/p as a workaround.
>
> Mandy
>