Initial webrev with changes for JDK 9

[Seán Coffey]

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.