The module system (JSR 376 and JEP 261), was integrated into JDK 9 last week and is now available for testing in early-access build 111
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).
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
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.