Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News What We Know about Java 16 and 17 So Far

What We Know about Java 16 and 17 So Far

This item in japanese

Lire ce contenu en français

Oracle recently released version 15 of the Java programming language and virtual machine. In the new OpenJDK release cadence, this means that work has already shifted to version 16, which is due to be released in March 2021. New features include procedural upgrades, new APIs and tooling, operating system ports, strongly encapsulating JDK internals by default, and more.

The new features announced can be subdivided into several categories, starting with some procedural upgrades for how OpenJDK is developed:

  • Migrate from Mercurial to Git (JEP 357)
  • Migrate to GitHub (JEP 369)
  • Enable C++14 Language Features (JEP 347)

There are some new APIs and tooling - most of them still in incubating form:

  • Vector API (Incubator) (JEP 338)
  • Foreign Linker API (Incubator) (JEP 389)
  • Foreign-Memory Access API (Third Incubator) (JEP 393)
  • Unix-Domain Socket Channels (JEP 380)
  • Packaging Tool (JEP 392)

The first three of these are the delivery of aspects of Project Panama, which is the OpenJDK project to improve the ability of JVM managed code to interoperate with well-defined but "foreign" (i.e. non-Java) APIs. In particular this will include interfaces commonly used by C libraries. Panama can be thought of loosely as a "re-imagining of JNI", but it contains a lot more than that. These JEPs are still incubating, and will not become final until a future version of Java.

Another category of JEPs being delivered is minor improvements to the VM:

  • Elastic Metaspace (JEP 387)
  • ZGC: Concurrent Thread-Stack Processing (JEP 376)

The first of these enables the JVM to release unused memory from the internal metadata area back to the operating system and the second is a speed improvement for the ZGC garbage collector.

A number of new ports of OpenJDK to different operating systems are expected:

This includes the first official and supported port of Alpine Linux in mainline OpenJDK (although Azul systems have offered paid support for Java on Alpine for some time).

The ports category may also include JEP 391 (macOS/AArch64 Port), which is the port that will enable Java on Apple Silicon. This is underway and has the backing of both Azul Systems and Microsoft (learn more in Monica Beckwith's recent QCon talk) but has not officially been targeted for Java 16 yet - but the project team have discussed the possibility that it will ship as part of the release.

A further category is the next iteration of Project Amber features:

  • Pattern Matching for instanceof (JEP 394)
  • Records (JEP 395)
  • Sealed Classes (Second Preview) (JEP 397) (tbc)

We have previously covered records and sealed classes at InfoQ - but note that the Second Preview of Sealed Classes is still not targeted at Java 16 yet, but it is likely to be.

One other developer-facing feature that is targeted at Java 16 is:

  • Strongly Encapsulate JDK Internals by Default (JEP 396)

This is the next step in a journey to close off access to the JDK internals, to allow the OpenJDK development team to move faster. This does not include the famous sun.misc.Unsafe class, which was moved to the jdk.unsupported module and will continue to be available.

Java 16 is not a long-term support (LTS) release, so it is unlikely to see widespread adoption - based on the fact that no previous non-LTS release has.

The next LTS release is scheduled to be Java 17 according to the roadmap. This is due in September 2021, and as yet no features have definitively been announced as targeting it.

However, the contents of version 16 can allow us to infer some things about Java 17. This is because Java 16 is the last opportunity to add Preview or Incubating Features before the next LTS release. Oracle has typically been cautious and not delivered major new features without at least one round of previewing the feature.

At this stage, there are no indications that either Project Valhalla (addition of inline types, and a re-imagining of the JVM's low-level data model) or Project Loom (addition of VM-managed "virtual threads" and a substantially augmented concurrency model) will be ready to ship as Preview by next March. As a result, it seems fairly likely that these new initiatives will not be available as final features in the Java 17 LTS release.

This means that, as far as we can predict now, of the four major projects underway in OpenJDK (Valhalla, Loom, Panama and Amber) - none of them will be completely delivered by next September.

With luck, we may have delivery of a decent chunk of Amber - both Records and Sealed Classes as final features, but the pattern matching work will still be very incomplete - with only switch expressions and instanceof patterns as fully delivered features. Some of the Panama JEPs (especially JEP 393, which is at Third Incubator in Java 16) may also be finalized, but not all of them. This is still progress and valuable to the community, but it is rather underwhelming compared to the scope and promise of the projects.

Oracle staff frequently express the opinion that there's nothing special about LTS releases, and they are merely a designation that is a part of Oracle's support business and are not of wider significance. This is true, from a technical perspective, but the situation on the ground has not changed - very few teams are willing to adopt the six-monthly forced upgrade cadence of Java versions and instead are continuing to use Java 8 and 11 - even if it means switching away from Oracle as a Java vendor. There are no indicators that suggest that this trend will change in 2021.

If Java 17 does become the next LTS release, the community may decide that "half a loaf is better than none" - it would have some nice features (Class Data Sharing, JFR Streaming, Records, Switch Expressions, etc) as well as heap of performance and other internal improvements. It could end up being something of a damp squib - and it would be rather disappointing to be faced with another three-year wait before the next LTS (assuming the established pattern of the majority only upgrading LTS to LTS continues) and the full delivery of the features that the community actually cares about. Adoption of such a release may well be slow - perhaps even slower than adoption of Java 11 has been.

However, another possibility is that Oracle could decide to change the cadence of LTS releases and opt not to make Java 17 an LTS, and instead wait until more of the features were in a final state. For example, a one-year delay of LTS to 2022 (Java 19) could well give enough time to get the rest of Amber, Loom, more of Panama and perhaps even Valhalla to a finished and releasable state. This would be a change to their roadmap, and would require another year's wait, but it could result in a much more complete and compelling release to re-energize the community and refresh Java for the coming decades.

Rate this Article