On September 21st, Java 9 arrived. More than three years after Java 8, a major Java release is finally in the hands of developers. The big question is: what do the changes in Java 9 mean for you?
Java 9 marks a turning point in the release cycle of Java. Before we get to that, we’ll discuss new developer-facing features in Java 9. From an operational perspective, there are enhancements to security and performance. But there’s a lot more to unpack in this release. I’ll review five of the most exciting changes that should encourage you to adopt Java 9.
Let's start with the most prominent feature of Java 9: the Java Platform Module system. A long-standing problem with Java was its monolithic runtime library. Twenty years of development on a platform as large as Java takes it toll. Many classes got entangled—just like you'd expect in a large monolithic code base. Even more troubling was the fact that there was no real way to encapsulate private implementation classes in the JDK. This led to a proliferation of external libraries depending on these internal details, and this hampered the evolution of the platform.
With Java 9, the JDK itself is modularized and ships with around 90 distinct modules. A module groups related packages. Only packages that are explicitly exported from a module are accessible to other modules. Finally, internal implementation classes can be truly encapsulated. Additionally, modules can express explicit dependencies on other modules. These dependencies are always verified by the module system both at compile-time and run-time.
Modules can be used to modularize applications as well and not just the JDK itself. Instead of using the brittle classpath (where duplicate, missing or inconsistent JARs go unnoticed until run-time), you can now create your own modules with encapsulated packages and explicit dependencies.
Modules offer a way forward to better structured and more reliable applications. However, the Java module system will not change the Java landscape overnight. Modules affect the design of your application and are manifest in all phases of development: development, compilation, packaging and at run-time. It will take time before widespread adoption of the module system is in place. Fortunately, many migration scenarios are supported to gradually move towards modularized applications and libraries. You can learn more about working with modules in Java 9 with this course.
Besides the module system, Java 9 is packed with small features improving productivity for developers. For example, collection factory methods allow you to create immutable collections with pre-defined elements in a single statement. No more awkward workarounds necessary to create small pre-defined collections.
Another major productivity booster is JShell, a Read-Eval-Print-Loop for Java code. Instead of compiling and running small classes to test-drive code, you can interactively type and evaluate snippets of Java in JShell. Exploratory programming takes on a new meaning when you get instant feedback from a REPL. JShell is already integrated with IDEs like IntelliJ IDEA, allowing you to open an interactive environment with access to your application's code.
Developer productivity features are far from the only reason to adopt Java 9. The platform itself has gained many new features improving security as well. Most security improvements in Java 9 relate to secure networking. The most recent versions of (D)TLS are now supported for secure HTTPS connections. Additionally, certificate stapling (allowing efficient checks of certificate revocation) is supported.
Another security improvement is the ability to filter incoming serialization data. Serialization has been the bane of Java's existence, leading to many security exploits in the past years. You can now take a whitelist or blacklist approach to filtering incoming serialization data streams, minimizing the attack surface of Java serialization.
Running on a new version of Java often means getting performance improvements without changing any code. Java 9 is no exception. One example of such an improvement is the Compact Strings feature. Any string that can be fully represented with just the ASCII character set (as opposed to strings containing characters from the full Unicode character set), is stored with a single byte per character. Strings that have characters outside of the ASCII range take up their usual two bytes per character. Most applications have a fair amount of String objects on the heap. If these are 'simple' Strings this translates into a nice reduction of memory use.
Another important change in Java 9 is the switch to the G1 (Garbage First) Garbage Collector as default garbage collector. Designed to be used with large heaps, it offers tuneable pause-time goals and it can do incremental garbage collection. The impact of this change depends on the characteristics of your applications. In general, you'll get lower latency code execution with less 'stop-the-world' GC pauses. In turn, G1GC utilizes slightly more CPU power to achieve this. At any rate, it’s important to test the behavior of this garbage collector on your particular applications when moving to Java 9. In some cases, allocation patterns don't quite suit the approach G1GC takes and switching to another GC (or tuning G1GC) is necessary.
Learn more about the new features relating to developer productivity, security and performance with this course.
5. Release cycle
So far we've focused on features that are in Java 9. But there's another reason why Java 9 is an important release: it marks the end of the era of 'feature-driven' Java releases. In the past, some big features were selected, and whenever they were ready, a new major Java release was made. In practice, this led to at least three years between major releases. That's not acceptable in this day and age, so the Oracle and the OpenJDK project are switching to time-based releases.
Now, every 6 months a new version of Java will be released. It will contain whatever features are ready by that time. Between these 6 month releases, updates with critical fixes can still be released when necessary. This new release schedule has several implications. First, Java releases become both more frequent and predictable. The current plan is to release Java in March and September of each year. The new proposed version number scheme to increment the major version every six months, meaning the next release in March 2018 will be Java 10. However, the version scheme is still under discussion.
Upgrading your Java version every 6 months is not an enticing prospect for many organisations. Therefore, there will be long-term-support (LTS) versions designated every three years. The first LTS release will be the release of September 2018. That also means Java 9 will not be on of the long-term supported releases.
So, is Java 9 right for you?
Does the new release schedule mean that you shouldn’t adopt Java 9 and wait for the first LTS release end of next year instead? From an operations perspective, that is an attractive strategy. From a development perspective, there are too many important changes arising from the modularized JDK to put off adoption.
My advice is to start developing your application on top of Java 9 as soon as possible. You don't have to use modules for your application when moving to Java 9—they’re completely optional. Nevertheless the JDK is modularized, so you’ll need to deal with the new reality of encapsulation in the JDK. Even if your application runs on the classpath, postponing the move to the modular JDK makes it harder and more costly to deal with later.
One option is to start using JDK 9 to develop your applications, but still target JDK 8 as runtime. A newly introduced '--release' flag supports this scenario. This course of action prevents an immediate upgrade to your infrastructure, but at the same time precludes you from benefitting from new APIs and performance and security enhancements. Adopting Java 9 quickly allows you to get ready for the first long-term-support release next year. After that, you can always choose to remain longer on this LTS version.
Currently, the Oracle JDK builds off OpenJDK, but adds several proprietary tools and features. Looking into the future, Oracle has also announced it will open-source the commercial features that are part of the Oracle JDK builds. The OpenJDK project is also going to ship its JDK binary distributions under a GPL license. In the end, the Oracle and OpenJDK binaries should converge. Again, this is a big change to the current situation and a big step towards a more open Java.
These new release policies make Java more agile than it ever was. Large features will be broken down into incremental steps and delivered every 6 months. Features ship whenever they're done, and if they miss a release, there's always another one just 6 months away. Even after more than 20 years, Java is still moving forward at an exciting and accelerating pace.
Ready to adopt Java 9? Try our technology learning platform.