Module views with exports support

Mandy Chung mandy.chung at oracle.com
Fri Dec 30 09:42:16 PST 2011


A new webrev for the module views [1] with the exports support:
    http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-views.01/

High-level summary:
   - Introduced a new ModuleView class and Service.Dependence
     Service.ProviderInfo classes. Each ModuleInfo has one or
     more views.
   - Renamed ModuleIdQuery to ModuleViewQuery
   - Renamed methods in the Catalog class to return ModuleId for
     module views.  E.g.
       gatherLocalModuleIds ->  gatherLocalModuleViewIds
       listModuleIds        ->  listModuleViewIds
       findModuleIds        ->  findModuleViewIds
       findLatestModuleId   ->  findLatestModuleViewId
   - Linker is updated to link with types that are exported by
     its dependence and only exported set of remote packages are
     stored in the configuration.

I also considered renaming ModuleId to ModuleViewId (not done in
the above webrev) but another thought would be to keep ModuleId
to represents a general identifier. I'd like to get your opinion
for this refactoring/renaming before moving forward.

With exports, a module can access types exported from a module
view that it requires.  A configuration has a set of contexts
and each context has a list of local classes and also a map
from a package name to a remote context.  Before exports, all
public types are exported. For a simple application that requires
the "jdk" module, the configuration size is reduced by 73% (6.3)

  8.6M   mlib-tip/com.greetings/0.1/config
  2.3M   mlib-views/com.greetings/0.1/config

If it requires jdk.base, the configuration size is much smaller
as jdk.base has fewer public classes than jdk.  With exports,
the size is reduced by 8.7% (72K).

  824K   mlib-base-tip/com.greetings/0.1/config
  752K   mlib-base-views/com.greetings/0.1/config

This is the module-info.java requiring the jdk module
(the current default platform module).
----------------------
module com.greetings @ 0.1 {
     requires org.astro;
     class com.greetings.Hello;
}

module org.astro @ 2.0 {
     exports org.astro;
}
----------------------------

For the JDK modules with exports [2], the system module library size
is reduced by 8M (7.6%):

  105M   jigsaw-repo/jdk/build/linux-i586/lib/modules
   97M   jigsaw-views/jdk/build/linux-i586/lib/modules

It is still big in the current prototype and we expect that the fast
configuration work will further reduce the footprint (this is work in
progress).  The number here is just to compare the size before and
after with exports support.

Thanks
Mandy

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2011-December/001813.html
[2] http://cr.openjdk.java.net/~mchung/jigsaw/webrevs/module-views.01/module-info/jdk-modules-with-views.txt
[3] http://cr.openjdk.java.net/~mchung/jigsaw/views-api/




More information about the jigsaw-dev mailing list