The long awaited Java SE 9.0 is releasing on September 21,2017, and with it come some major changes.
The long awaited Java SE 9.0 is releasing on September 21,2017, and with it come some major changes.
According to Oracle, some of the key changes in JDK 9 include the introduction of « a new kind of Java programming component, the module, which is a named, self-describing collection of code and data ». This module system introduces a new optional execution phase, link time, in between the compile time and run time. During this phase a set of modules can be assembled and optimized into a custom runtime image. A new modular JAR file with a module-info.class file in its root directory is also introduced.
The JDK itself has also been modularized, an approach intended to improve performance, security and maintainability.
The introduction of the jshell tool brings Read-Eval-Print-Loop (REPL) to the Java platform. This will facilitate prototyping and exploration of coding options with immediate results and feedback.
InfoQ spoke to editor Ben Evans, also co-founder of JClarity and executive committee member of the Java Community Process (JCP) 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.0 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 (that basically does 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.
Evans likes jShell as a teaching and exploration tool.
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:
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.
Verburg 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 is excited to see the inclusion of jShell in Java 9. 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.
Evans and Verburg are both a bit disappointed 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.
Other changes include the removal of
rt.jar and tools.jar from the Java runtime image.
A complete list of changes coming in JDK 9 can be found on Oracle’s website .
