The Rebirth of Java

Java has been declared dead more than any other programming language, it seems. Perhaps unsurprisingly, reports of its death are greatly exaggerated. Java has an enormous footprint in backend development and most enterprises develop systems in Java. However, there’s a kernel of truth in every rumor — Java was a slow-moving language in the age of dynamic languages like Ruby and JavaScript. Traditionally, major Java releases spanned three to four years of development. It’s hard to keep up with other platforms at this pace.

In 2017, all this changed. Oracle — Java’s steward — announced the Java platform would be released twice a year. Java 9, released towards the end of 2017, was the last big and long-awaited release. After Java 9, every year in March and September a new major Java release is delivered. Like clockwork.

Switching to this time-based release schedule has many consequences. Releases can no longer wait on features that are not yet complete. Also, because there’s less time between releases and the team developing Java remains the same size, fewer features make into a release. But that’s okay — we get another release in only six months. A steady stream of new features and improvements is what we can count on.

Interestingly, new language features are now also delivered incrementally. The Java language is now evolving in a more agile manner. For example, Java 12 shipped Switch Expressions as a preview language feature, with the express intent of later extending this feature to support full pattern matching.

One of the reasons why Java releases took so much time and effort, is that the platform became somewhat ossified in its 20+ years of existence. In Java 9, the platform is fully modularized. Every part of the platform is now put into its own module, with explicit dependencies on other parts. The module system introduced in Java 9 ensures this platform architecture is adhered to from now on.

Platform internals are now safely encapsulated inside modules, preventing (ab)use by application and library code. Previously, many applications and libraries depended on these platform internals, making it hard to evolve Java without breaking lots of existing code. It’s also possible to use the module system for your own applications. It can make your codebase more maintainable, flexible, and future-proof as well.

Moving from a long and unpredictable release cycle to regular calendar-based releases is a great achievement by the Java team. Adapting to this new reality has definitely taken time for us as a developer community. Fortunately, the changes in Java are now smaller and more incremental. These more frequent and regular releases are easier to adopt and adapt to.

For slower movers, a version of Java is marked as Long-Term Supported (LTS) every six releases, starting with Java 11. Meaning, you can move between LTS releases every three years if you want. It’s important to understand that the LTS commitment is offered by vendors like Oracle, Red Hat, or even Amazon, and is not necessarily free of charge. In any case, the vendor-neutral OpenJDK project keeps producing supported builds for the latest Java release that is developed. Many things may and will change in releases between the LTS releases though. If you can, hop on the frequent release train and enjoy a steady stream of better Java. It’s not as scary as it may sound.