The long awaited next release of Java SE, version 9, is being released on September 21, 2017 and with it come some major changes.
The key change in JDK 9 is the introduction of "a new kind of Java programming component, the module, which is a named, self-describing collection of code and data", according to Oracle. The key aim of the modules technology is to reduce the size and complexity of both Java applications and the core Java runtime itself. To this end, the JDK itself has been modularized, an approach that Oracle intends to improve performance, security and maintainability.
To support Java 9 modules, a new modular JAR file with a module-info.class file in its root directory has also been introduced. Oracle has also introduced tooling to allow a set of modules to be assembled and optimized into a custom runtime image, without requiring a full Java runtime to be present. Other changes as a consequence of modularisation include the removal of rt.jar and tools.jar from the Java runtime image.
InfoQ spoke to Ben Evans, a member of the Java Community Process (JCP) Executive Committee, about his thoughts on the module system in Java 9.0
Evans: I think the applications that are in the most dire need of refactoring may be the best targets for modularisation. If you're already in Lava Flow / God Class / Stovepipe System hell and your stakeholders know it, then it may be easier to persuade them to do a full drains up refactor and that the incremental effort to go to a fully modular solution (vs just refactoring and moving to Java 8) is worth it.
Since Oracle has announced that Java 8 will be a long-term support release, supported through 2022, Evans thinks that a lot of applications might stay on Java 8 and not upgrade to Java 9 at all. Evans added that some applications may decide to leave the dev and build toolchain on version 8 and use a Java 9 runtime in production.
This could make a lot of sense for certain applications. For example, I've seen ecommerce sites with large heaps that contain ~40G of string data. Java 9's Compact Strings would cut that memory usage in half. That would, in turn, have a positive impact on GC performance. For some applications (including perhaps large Solr installations or similar), that single benefit may itself be worth upgrading to 9 at runtime.
Java 9 makes G1 the default garbage collector replacing Parallel GC, which was previously the default. Evans commented on this change:
This change can be significant, because G1 does more work on the application thread than Parallel (which does basically none, and relies on the GC threads to do virtually all of the work to manage memory). This means that switching to G1 will introduce extra work on the app threads and impact performance of the application directly.
In many cases (perhaps even most) this additional performance overhead is not an issue. However, in the field, I have observed that a significant percentage of workloads do see an observable decrease in performance when moving from Parallel to G1. For some of these applications, this performance degradation is unacceptable, and so they are unable to move to the G1 collector. With G1 becoming default, this now potentially affects every application moving to Java 9.
InfoQ asked Martijn Verburg, CEO of JClarity and co-organizer of London Java User Group, if it is advisable for large code bases to refactor into modules.
Verburg: Yes and hopefully the large code base that you are dealing with has already been split into some semblance of a modular structure whether that be via OSGi, Maven modules, JBoss Modules or just a set of home grown rules about a clear package and interface structure.
Verburg has some good common modularisation advice and also points out things developers should watch out for when adopting Java 9’s module system:
- Read Paul and Sander's book on Java 9 modularity- it's the definitive guide, which covers all of the gotchas and how the relationship between modules, packages and JARs work.
- Have well defined interfaces at the boundaries of your modules and code to those interfaces.
- Don't have split packages, that is, your packages must not be split across two modules. The Adopt OpenJDK programme's Patrick Reinhart has a detection tool that you can run on your existing code.
- Make sure you don't have cyclical dependencies (Jigsaw won't allow them).
- The way modules are laid out in source will look differently than what you're used to; make sure that your build tools can cope accordingly.
- Jigsaw does not support versions.
According to Verburg, the key things are to fix up cyclical dependencies, split packages and make sure to code to interfaces. This should be done to existing code base before attempting modularisation with Jigsaw. He also addressed the myth that only modularised applications can run on Java 9.
There's been a bit of FUD going around where people have mistakenly said that you need to have a modularised app in order to run on Java 9. This is simply not true and you can run your existing classpath based applications on Java 9 just fine. There are a few new security restrictions, which means you may need to set a few special runtime flags (until you refactor your code to use the new safer way of accessing Java internals etc.), but even there the default is to warn you, as opposed to stopping you (Java 10 will enforce that further).
Verburg thinks Jigsaw is the foundation that will allow Java to move faster, and credits Mark Reinhold, Alan Bateman, Mandy Chung and the rest of the Jigsaw team who worked tirelessly for many years to make that happen.
Java 9 also introduces the jshell tool. This command line environment brings a form of Read-Eval-Print-Loop (REPL) to the Java platform. This is intended to facilitate prototyping and exploration of coding options with immediate results and feedback.
Both Verburg and Evans are excited to see the inclusion of jShell in Java 9, although they also mention disappointment that HTTP/2 is shipped as an incubator module in Java 9. Given considerable community interest in this feature and offers of help, Evans thinks Oracle should have committed sufficient engineering resource to ship HTTP/2 as GA.
A complete list of changes coming in JDK 9 can be found on Oracle’s website. With the announced switch to a six-month release cycle, the release of Java 9 represents the last of the releases driven by "keystone" features that have characterized Oracle's stewardship of Java to date. The next phase of Java's evolution seems set to be driven by shorter, feature-oriented releases. It remains to be seen whether this will allow Java to retain its position among leading serverside technologies.