JDK 16, the implementation of v16 of the Java SE Platform, has landed bang on time, providing developers with refined language features and a finished packaging tool to make distributing their apps a little easier. 

Since the last release the project was also able to finish the migration from version control system Mercurial to git and bring its code base to GitHub. The latter move is aimed at meeting devs where they are and lowering the initial barrier for new committers, which might be necessary to keep the language growing.

Java 16 saw a couple of language features maturing into general availability, the most anticipated surely being Records, and pattern matching for instanceof. Both were introduced in JDK 14 to make dev’s lives easier by offering a concise way to model plain data aggregates and test the structure of an expression respectively. 

The new versions, which are now available, have been fitted with a couple of refinements, allowing inner classes to declare record class members, and adding a compile-time error for cases in which instanceof expressions are pointless.

The Java team also introduced what it calls elastic metaspace, a feature making use of the “buddy-based allocation scheme” present in the Linux kernel, to free up memory occupied by unused class-metadata quicker and allocate smaller chunks. Aside from reducing the off-heap memory usage of the HotSpot engine, this is also hoped to make the metaspace code easier to maintain, freeing up capacities that can then be invested into other parts of the project.

After spending two release cycles in the project incubator, packaging tool jpackage reached production-readiness in the current release. It is based on the legacy JavaFX tool javapackager and provides functionality to package self-contained Java applications and necessary dependencies in native formats deb and rpm, pkg and dmg, and msi and exe.  This is meant to provide application users with a familiar installation format and give devs an easy way to spread their creations amongst a wider audience.

While those features are ready to be used in production, JDK 16 also includes a couple of experimental additions such as the Vector and Foreign Linker APIs. The Vector API provides capability to write complex vector algorithms which can be found in areas such as machine learning and cryptography. Under the hood it makes use of the HotSpot performance engine which already sports auto-vectorization capabilities, though the new API is said to be more predictable and robust – traits pretty much necessary in the fields Java looks to make a name for itself with this.

The Foreign Linker API meanwhile looks to “simplify the otherwise error-prone process of binding to a native library”. It is part of Oracle’s Project Panama which looks to create a bridge between Java and native functions. Together with the Foreign-Memory Access API, which is also included in a new iteration, it is planned to serve as a basis for third-party native interoperation frameworks.

Other updates include functionality to use C++14 language features in JDK C++ code, a second preview of sealed classes, concurrent thread-stack processing in garbage collector ZGC, and support for Unix-domain sockets in socket and server-socket channels.

Over the last three years Java releases have come in at a stable rate of one every six months, which Director of Product Management for Java SE at Oracle, Aurelio Garcia-Ribeyro, says has made things a lot easier for the team working on improving the language. “Not only has it made, planning the releases a lot less stressful – because who are we kidding? If you’re planning a release three years into the future, you’re trying to guess what will be the highest priorities three years into the future, and nobody’s that good. 

“Now, we have a chance of setting our priorities and reviewing them every six months to make sure that what we’re working on is still the highest priority. And in the meantime, we deliver features just as they become available.”

This process also made for better feature quality, as the Java devs don’t have to hurry out of fear their creation won’t be available for another three years if they don’t make the next release.

Teams on the receiving end, feeling the pressure to keep up, however should breathe easy. “The goal of that six month release wasn’t that everybody in the world was going to deploy a new version every six months,” Garcia-Ribeyro said in a briefing last week, even though he finds that projects tend to keep up better with the more regular, smaller updates as the implementation of support for new features shows.

“If we thought that the reasonable thing to do would be for everybody to jump to the next LTS within the next six months, then you would only need six months of overlap between LTS.” Instead, he told DevClass, developers should consider what it is they need from Java. “My opinion is: new code – grab these new functions. The code that I can write today with JDK 16 [..] is much easier to maintain. So it would be foolish for me to develop a new application on Java 8, or Java 11, if I can do something better now.”

“But if you have something up and running, that’s not giving you problems – there’s no better code than the code that has been running for two or three years and has already got all the kinks worked out. If you want to continue applying updates to JDK 8 so that you get the better performance, the most up to date security algorithms [..]? You keep doing that and keep applying the patches. You’re good, enjoy JDK 8 until 2030.” 

If that’s a hint on the end of availability set for Java SE 8 or just a shameless plug for Oracle support remains to be seen. The next long-term support release, however, is planned for September 2021 – so there’s still a bit of time to prepare migration if necessary.