Review request: exports runtime support + jdk modules converted to use exports

[Mandy Chung]

  Updated webrev:
    http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/exports-full-webrev/

The only change to the previous version is in the 
SimpleLibrary.StoredConfiguration class that adds indirection for the 
context name that reduces the config file size bloat from 90M to 16M.  
There are other opportunities to improve the memory and runtime 
performance.  For example,
1. optimize for the whole package export case
2. another indirection for class names, package names, module names, etc

But I'd like to address these performance issues later to push this 
prototype out for anyone to play with.

The default requires is "jdk" which includes the tools modules that is 
an open issue to be addressed.  There was some discussion whether it 
should be JRE or just the base module.  In the meantime, I can change it 
to JRE that will reduce the config file to ~10M (the number of contexts 
from 40 down to 20).  I'll work with Jon to fix the default in a 
separate patch.

Mandy

On 6/7/11 4:39 PM, Mandy Chung wrote:
>
>
> I completed the changes for all jdk modules to use the new "exports" 
> statement.
> The module-info.java for all jdk modules is at:
>     
> http://cr.openjdk.java.net/~mchung/jigsaw/moduleinfo-exports/jdk-modules-module-info.txt
>
> Full webrev:
>    http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/exports-full-webrev/
>
> Summary of changes:
> 1. jigsaw runtime support for the new ModuleExports attribute (see [1])
>     This includes reading the new ModuleExports attribute from 
> module-info.class,
>     updating the context to build a map from a remote class to its 
> suppying context
>     (previously the key was a remote package name), and also the 
> simple library
>     now stores the list of remote classes rather the remote packages.  
> Also,
>     javac's implementation of ModuleInfo is updated to implement the new
>     exports() method.
>
>     The webrev in [1] has a temporary workaround that assume all 
> public types
>     of the platform modules are exported.  In this patch,  that 
> workaround is
>     removed.  The runtime will read the ModuleExports attribute for all
>     modules including the platform ones.
>
> 2. Modify the ClassAnalyzer to generate exports statement.
>     By default, a module exports  the supported APIs and it explicitly 
> lists
>     individual package using '*' wildcard. Internal APIs are only 
> exported
>     in the modules that are strictly for implementation use with the 
> base module
>     (see below).  Platform modules should only export the platform 
> APIs and
>     any other public supported APIs. '*' wildcard is preferred in this 
> case
>     rather than '**' to export all public types in all subpackages to 
> prevent
>     any internal subpackages from leaking out.  For example, jdk.desktop
>     exports individual packages e.g. java.awt.* and java.awt.dnd.* rather
>     that java.awt.** but java.awt.dnd.peer and java.awt.peer are 
> internal packages
>     that are exported in sun.desktop (internal module).
>
>     It also allows to specify
>     additional exports statement in the input config file.  When a module
>     reexports another module, it will export the APIs that are listed in
>     the "exported.packages" property defined in the input 
> modules.properties
>     file.  For modules that aggregate multiple modules (e.g. jdk, 
> jdk.jre),
>     it will coalesce all exported packages into a simpler export 
> statement
>     using "**" wildcard to reexport all "exported" types in all 
> subpackages.
>
>     modules.properties file includes a list of exported packages for 
> the platform
>     that is based on the CORE_PKGS.gmk and NON_CORE_PKG.gmk.
>
>     
> http://cr.openjdk.java.net/~mchung/jigsaw/moduleinfo-exports/jdk-modules-module-info.txt
>     shows all module-info.java of the platform modules.
>
>     jdk.base exports a few types in the sun.reflect.annotation package
>     since javac depends on them for supporting serialization of 
> annotation.
>     These 4 sun.reflect.annotation classes are essentially defacto 
> platform
>     classes.
>
>     There is some refactoring/clean up in the class analyzer that was 
> something
>      I did some time ago and I'd like to take this chance to get 
> reviewed.
>
> 3. This webrev also includes the fix I posted in [2] that the Linker 
> should check
>     if a supplying context and the requesting context are different 
> before adding
>     to the remote suppliers list.
>
> 4. The change in java.util.ResourceBundle and 
> sun.security.jca.ProviderConfig
>      are related to the use of system class loader to find classes in 
> ClassPath.
>      In the modular JDK, system class loader is the module class 
> loader for
>      the root module but the system classes/resources are not necessarily
>      visible to it (e.g. sun.security.provider.Sun and other internal 
> classes).
>      The Launcher.getBootLoader method is added as a temporary 
> workaround.
>       We'll examine the use of class loader in the jdk implementation 
> closer in the future.
>
> 5.  The change in ModuleId.java fixes a memory issue in loading a 
> configuration.
>      Some test failed due to OutOfMemoryError when there are large number
>      of ModuleId stored in a configuration (one in each local and 
> remote class)
>      but there are limited number of unique ones.  Instead of 
> returning a new
>      instance of ModuleId, ModuleId.parse() keeps a cache of all 
> unique ModuleId.
>
> 6. jmod dump-config is updated to print out the exports statement.
>
> $ jmod list -v jdk.javac
>
> jdk.javac at 7-ea
>   requires jdk.base@=7-ea
>   requires jdk.compiler@=7-ea
>   requires jdk.logging@=7-ea
>   exports com.sun.source.tree.*
>   exports com.sun.source.util.*
>   exports com.sun.tools.apt.resources.*
>   exports com.sun.tools.javac.*
>   exports com.sun.tools.javac.api.*
>   exports com.sun.tools.javac.code.*
>   exports com.sun.tools.javac.comp.*
>   exports com.sun.tools.javac.file.*
>   exports com.sun.tools.javac.jigsaw.*
>   exports com.sun.tools.javac.jvm.*
>   exports com.sun.tools.javac.main.*
>   exports com.sun.tools.javac.model.*
>   exports com.sun.tools.javac.nio.*
>   exports com.sun.tools.javac.parser.*
>   exports com.sun.tools.javac.processing.*
>   exports com.sun.tools.javac.resources.*
>   exports com.sun.tools.javac.sym.*
>   exports com.sun.tools.javac.tree.*
>   exports com.sun.tools.javac.util.*
>
> 7. jmod find-class<module-id> <class-name>
>
> I added this diagnostic comand to find which contexts a given class 
> can be found
> to help diagnosing ClassNotFoundException.  A class exists but if not 
> visible to a
> module class loader, CNFE will be thrown.   For example, this would be 
> useful
> to diagnose the CNFE thrown why it can't find the 
> sun.security.provider.Sun
> security provider.  Below is the sample output.
>
> $ jmod find-class jdk.base sun.security.provider.Sun
> configuration roots = [jdk.base at 7-ea]
>   class sun.security.provider.Sun found in:
>     context +jdk.base
>       remote +jdk.boot+sun.charsets+sun.jaxp+sun.localedata+sun.resources
>     context +jdk.jaxp
>       remote +jdk.boot+sun.charsets+sun.jaxp+sun.localedata+sun.resources
>     context +jdk.boot+sun.charsets+sun.jaxp+sun.localedata+sun.resources
>       module jdk.boot at 7-ea
>
> The above means that sun.security.provider.Sun is visible to the 
> module loader
> for the above contexts.  It's defined locally from jdk.boot at 7-ea module.
>
> $ jmod find-class jdk.base sun.security.pkcs.SunPKCS11
> configuration roots = [jdk.base at 7-ea]
>   class sun.security.pkcs.SunPKCS11 found in:
>     none
>
> Mandy
>
> [1] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-May/001292.html
> [2] 
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-May/001308.html
>