I'm hoping we can bulk up some of the new exception handling. I've put
suggested edits for the jdk repo together in a webrev. No major edits
here but it should help supportability of the code for the future. Will
it be possible to import these in before the bulk push ?
http://cr.openjdk.java.net/~coffeys/webrev.jake_edits/webrev/
Regards,
Sean.
On 03/03/2016 14:38, Alan Bateman wrote:
I've pushed webrevs with the initial changes for JDK 9 here:
http://cr.openjdk.java.net/~alanb/8142968/0/
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 descriptions.
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
javax.lang.model APIs.
There are a lot of updates to existing tests in the webrev and many
new tests too.
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 is lost).
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
locale providers.
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 mentioned above.
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 line options.
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.
-Alan.
