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

[Mandy Chung]

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