We live in interesting times for Java. As a platform, Java has changed more in the last year than it had in the preceding five. In this article, JAX London speaker Simon Ritter will go over the current state and future directions for the Java platform.

Last year, JDK 9 was finally released after a series of delays. This release included a somewhat contentious feature, the Java Platform Module System (JPMS). I’ve given a lot of presentations both to customers and at conferences since then and it’s given me a chance to poll a broad cross-section of Java developers about their Java use. What’s become clear is that adoption of JDK 9 and even JDK 10 is almost non-existent. At the moment, the vast majority of developers are quite happy using JDK 8. This version is stable, secure, and includes functional programming elements not seen before in Java.

There are two reasons that a new version of Java is not proving a hit, even though would typically attract a number of early adopters.

First, there is a major change in strategy for the development of the JDK. In the past, developers have been reasonably confident that code developed on one version of Java will run on later versions without change. In reality, this has not always been the case. JDK 1.4 added the assert keyword and JDK 5 added enum, which meant you couldn’t use these as variable names anymore. Neither of these changes broke much code and the changes required to get your application working again were trivial. There are a couple of other things that have changed along the way, but I’ve taken code compiled on JDK 1.0 and run it without change on JDK 8. There really aren’t many development platforms that can say that.

SEE ALSO: How do we define Java?

One of the key reasons for this level of backward compatibility has been that new APIs and features have been added to Java, but nothing has been removed. This is in spite of the nearly 500 API elements having been deprecated since JDK 1.1. Whilst this is good for moving applications to newer versions of the platform without change, the technical debt of the JDK itself has become unmanageable. The decision was made that it was time to start removing antiquated features with the JDK now using JPMS as well as adding new ones.

The basic idea of JPMS is to divide the monolithic core libraries (which have grown from roughly 200 classes in JDK 1.0 to 4,500 in JDK 8) into more manageable pieces. By doing this, it is possible to create Java runtimes tailored to a specific application, only including the modules required by the application. Given the popularity of developing and deploying applications as a set of microservices, this is a very sensible idea.

JPMS also includes a second major change, which is the encapsulation of all internal JDK APIs. These are APIs not intended for general use; there is no public documentation for these APIs and developers have always been explicitly warned not to use them. They have also been warned that these APIs may be removed without notice.

The reality is that, whilst most Java application developers don’t use these APIs, those who develop frameworks and libraries often do. This led to a lot of potential problems breaking many applications. The JDK developers reversed their stance on this and introduced a set of command line switches that enable applications to override the encapsulation.

The second and more substantial reason for the lack of adoption of either JDK 9 or JDK 10 is the significantly faster release cadence of the JDK. Rather than planning a set of features that had to be completed before a JDK could be released we now have a time-driven model of a new release every six months.

SEE ALSO: Spring Framework 5.1 is here, with JDK 11 as its preferred long-term support

Clearly, it is not feasible for Oracle to support all of these releases as their number will proliferate over time. The decision was made to use a Long Term Support (LTS) model, that is similar to the one used by people like the Ubuntu community. A new LTS release will occur every three years. To get things started, JDK 8 was classified an LTS, and the next one will be JDK 11. When looking at migrating applications to a newer JDK, many developers have decided to wait for JDK 11.

Unfortunately, the logic behind this decision might seem sound but is missing some subtle announcements from Oracle regarding the availability of updates to the JDK.

In the past, we were used to the current JDK having public updates and a period of overlap for these updates, even after the next release came out. This has varied from a little over a year to nearly three years, allowing users to migrate between JDK revisions at a time that is most convenient for them. Testing and stability can be assured before the move is made.

This will no longer be the case. Starting with JDK 9, public updates are only available until the next release of the JDK, i.e. six months. Oracle has also switched to providing two binaries of the JDK: the traditional Oracle JDK under the Oracle Binary Code License and a new OpenJDK-based binary under a GPLv2 with classpath exception license. As of JDK 11, the Oracle binary that most people have been using for deployments are only available for development and testing. If you want to use the Oracle binary for a commercial application, you will need a support contract from Oracle with its associated costs. Azul Systems provides an alternative build of OpenJDK called Zulu. This is a direct replacement that requires no coding or configuration changes to use. Community builds of Zulu are free to download and use, and there is a very reasonably priced commercial option (Zulu Enterprise) with timely security updates and bug fixes.

SEE ALSO: JDK 12 patrol: Packaging Tool joins the party

There are many great ideas for the future directions of Java. OpenJDK projects like Valhalla for value types, Project Amber for simplified syntax and Project Loom for massive multithreading are just three. Clearly, the Java platform is not standing still and developers will want to continue to update to newer and better versions of the JDK. How quickly and easily that happens remains to be seen.

love me like you do