Project Jigsaw is an enormous effort, encompassing six JEPs implemented by dozens of engineers over many years. So far we’ve defined a modular structure for the JDK (JEP 200), reorganized the source code according to that structure (JEP 201), and restructured the JDK and JRE run-time images to support modules (JEP 220). The last major component, the module system itself (JSR 376 and JEP 261), was integrated into JDK 9 earlier this week and is now available for testing in early-access build 111.
Breaking changes Like the previous major change, the introduction of modular run-time images, the introduction of the module system might impact you even if you don’t make direct use of it. That’s because the module system is now fully operative at both compile time and run time, at least for the modules comprising the JDK itself. Most of the JDK’s internal APIs are, as a consequence, fully encapsulated and hence, by default, inaccessible to code outside of the JDK.
An existing application that uses only standard Java SE APIs and
runs on JDK 8 should just work, as they say, on JDK 9. If,
however, your application uses a JDK-internal API, or uses a library or
framework that does so, then it’s likely to fail. In many cases you can
work around this via the -XaddExports option of the javac and java
commands. If, e.g., your application uses the internal
sun.security.x509.X500Name class then you can enable access to it via
the option
-XaddExports:java.base/sun.security.x509=ALL-UNNAMED
This causes all members of the sun.security.x509 package in the
java.base module to be exported to the special unnamed module
in which classes from the class path are defined.
A few broadly-used internal APIs that cannot reasonably be implemented
outside of the JDK, such as sun.misc.Unsafe, are still accessible for
now. As outlined in JEP 260, however, these will be removed in a
future release after suitable standard replacements are available.
The encapsulation of JDK-internal APIs is the change you’re most likely to notice when running an existing application. Other relevant but, for the most part, less-noticeable changes are described in the risks-and-assumptions section of JEP 261.
If you have trouble running an existing application on JDK 9 build 111 or later, and you think that’s due to the introduction of the module system but not caused by one of the changes listed in JEPs 260 or 261, then please let us know on the jigsaw-dev mailing list (you’ll need to subscribe first, if you haven’t already), or else submit a bug report via bugs.java.com.
New features If you’d like to start learning about the module system itself, the video of my Devoxx BE 2015 keynote gives a high-level overview and The State of the Module System summarizes the design of the module system proposed for JSR 376. Further details are available in the six Jigsaw JEPs, listed on the main project page, and in videos of other sessions given at JavaOne 2015 and Devoxx BE 2015.
The module-system design will continue to evolve in the JSR for a while yet, based on feedback and experience. The implementation will evolve in parallel in the Project Jigsaw “Jake” forest, and we’ll continue to publish bleeding-edge early-access builds based on that code, separately from the more-stable JDK 9 builds.