2016-03-03 14:38:53 UTC
This is a snapshot of what is currently in the jigsaw/jake forest. Our
mission over the next few weeks is to iterate on this and get it to the
point where we + Reviewers are happy that it is a reasonable/acceptable
state to bring into JDK 9. We will need to set a deadline so that we can
plan the integration, more on this soon. As per our previous milestones
(JEP 201 and JEP 220) then we'll ask that the integration from jdk9/dev
to master skip a beat so that the module system is the only change in
master that week.
It's important to remember that the initial push to JDK 9 is exactly
that, it's not the final bits. There are many areas that still need
work, there are many open issues, there is an ongoing JSR, and of course
there will be ongoing feedback that will help us get it right.
Another important thing to say is this isn't a module system design or
API review. Questions/comments on the module system design can be
brought up here of course but we might have to punt to
jpms-spec-comments on topics that involve JSR discussions. For the API
then I expect it will go through many iterations, as every good API does.
The following is a summary of what is in each repository, this might
help to get a feel for where the implementation is currently at.
** top-level repository **
Most of the build changes have already been pushed to JDK 9 as part of
JEP 201 and subsequent iteration. There are some additional
jake-specific build changes, most of it is in the top-level repository
with some changes in other repositories too.
Of significance is that the temporary modules.xml document in the root
directory is gone, this has been replaced by a module declaration in the
source code of each module. The other significant thing is that the
build creates a packaged module for each standard and JDK module. It
also uses the jlink tool to create the JDK and JRE run-time images.
Erik Joelsson will take point for all the build changes, with help from
Reviewers from the build group.
** hotspot repository **
At a high-level, the changes in hotspot repository adds support for
modules to the virtual machine with access control extended to modules.
Startup has been significantly reworked into a sequence of phases, akin
to runlevels, so that the module system is initialized before any code
outside of the base module is loaded.
What we used to know as the boot class path is mostly gone except for
agent and -Xbootclasspath/a cases. Classes are instead loaded from
modules defined to boot loader. There is also support for patching
modules for testing and ad hoc needs.
JNI has new functions, as has JVM TI with initial support for debuggers
and agents that instrument code in modules. There is additional work on
JVM TI in progress so expect to see more in later webrevs.
There are a number of diagnosability improvements, include improved
exception messages and support for module details in stack traces.
There are many new tests. There are also updates to many existing tests.
Christian Tornqvist is planning to bring at least some of test changes
into jdk9/dev so we should see the patch reduce a bit once we sync up.
Lois Foltan will take point on the hotspot repository, she has lined up
several Reviewers in the hotspot group to help.
** langtools repository **
As expected, the javac compiler is significantly updated to support
compilation containing module declarations. The javadoc tool and doclet
code has also involve significant changes.
When compiling then there are several new command-line options, support
for module paths, and new compilation modes. JEP 261 has useful
The jdeps tool has been upgraded with many new options. The javap tool
has also been updated.
This repository also has the initial updates to the javax.tools and
There are a lot of updates to existing tests in the webrev and many new
Jonathan Gibbons will take point for the langtools repository and I
expect will use Reviewers from the compiler group to help get through this.
** jdk repository **
There are a lot of changes in this repository.
One of the most obvious is that there is a module-info.java source file
in each module's directory.
There is a new java.lang.module API to support module descriptors and to
create configurations of modules. There are new APIs in
java.lang.reflect to represent modules and layers of modules.
There are is a lot of support code for the module system itself, for
example ModuleBootstrap is the class that creates the configuration and
creates the boot layer.
The application and extension class loaders have been replaced with a
new implementation based on BuiltinClassLoader that supports loading
classes/resources from modules (in addition to the class path). Note
that there are no changes to class loader hierarchy and no changes to
visibility except that some non-core modules are no longer defined to
the boot loader.
In java.lang then Class and ClassLoader have several updates and new
methods to support modules. The legacy Package API and javadoc has also
been overhauled. The System class has been updated to support the
initialization of the module system.
Core reflection has been updated so that access control is aligned with
the Java Language and VM, except that it assumes readability (a
discussion point in the JSR at this time). Proxy has been significantly
updated so that the package, module and accessibility of the generated
proxy classes are in line with the accessibility of the proxy interfaces.
The MethodHandle API has also been updated but I expect there will be
changes soon on this, maybe additional lookup modes and changes when
teleporting from one module to another (as things stand then all access
The ServiceLoader API has been updated to support instantiating service
providers that are deployed as modules. It also has new support for
iterating over service providers in Layers.
The ResourceBundle API has been significantly updated to support
resources deployed as modules. There are also a lot of changes to the
This repository has the jlink tool (JEP 282) to assembly a set of
modules as a modular run-time image (JEP 220). The jlink tool is invoked
in the JDK build to create the JDK and JRE run-time images as I
The jlink tool includes an experimental API for developing plugins that
do transformations or optimizations at link-time. There are currently 11
plugins in the webrev, the most significant is the "installed-modules"
plugin that generates code at link-time to speed up the reconstitution
of module descriptors during startup.
There are significant updates to the jimage container implementation and
jrtfs. The most obvious that is there is now only one jimage container
(named "modules") in the run-time image.
The java launcher has been updated to support module paths and the other
command line options described in JEP 261.
The jar tool has been updated to support modules packaged as modular JAR
files. It has also been refurbished with support for GNU style command
JDI and JDWP have been updated to allow debugger enumerate and
introspect modules in the target VM. java.lang.instrument has initial
updates to support agents that instrument code in modules.
There are smaller changes in many others including updates to the
logging API, the JMX implementation, Image I/O, JNDI and several others.
Most of these changes are localized and should be straight-forward to
understand (esp as the code is organized by module).
There are lot of new tests. Some of the new tests aren't in the right
location yet and we'll resolve that soon. There are fewer updates to
existing tests that might be expected and this is because we've been
able to get the changes to several thousand tests into JDK 9 in advance.
Jim Laskey and Sundararajan Athijegannathan will take point for the
jlink, jimage and jrtfs changes.
For everything else then assume that Mandy Chung and I will take point
for now. We have approached many jdk9 Reviewers to help get through this.
** nashorn repository **
Nashorn has been updated to work with a modular runtime, including
spinning dynamic modules. This is the first of the dynamic languages to
get working and we'll need to learn from this to see what might
potentially need to exposed further in the API.
Sundar will take point on this, with Reviewers from the nashorn project.
** jaxp repository **
JAXP has a small update to support the XSLTC generating of translets in
modules at runtime. We need to re-visit this at some point to generate
the translets in their own layer.
** jaxws repository **
Most of the changes to JAXB and JAX-WS to work with modules are already
in JDK 9 and pushed to the upstream Metro project. There are API changes
so there will be updates to JSR 222 and JSR 224.
The residual changes in the jaxws repository are mostly handling of
resources in modules.
** corba repository **
No changes here except the module declaration.
I think that is mostly it for now. I will published new webrevs
periodically to take account of the ongoing changes.
On wider communication, then we'll send mail to jdk9-dev soon to make
everyone working on the JDK 9 project aware that we are starting to plan
the integration into JDK 9.