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

[Mandy Chung]

I should also mention that the stored configuration ought be optimized
for better performance in the future.  The stored configuration was
changed to keep a list of remote classes rather than packages so that
a module can export some public types of a package rather than the
whole package. This approach increases the number of entries in a
context's map to look up a supplying context for a given class quite
significantly and thus the size of the stored configuration.

For example, the number of remote entries of jdk.base module is increased
from 224 to 4495 entries.  This also impacts all modules requiring
jdk.base.

With remote classes:
   context +jdk.base
     module jdk.base at 7-ea
     remote (4495)

Before (remote packages):
   context +jdk.base
     module jdk.base at 7-ea
     remote (224)

The size of jdk.base/7-ea/config is also increased from ~450K to 1.3M.

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
>