What’s new in Java 16

In this article, we will check what was added and removed in Java 16.

Dmytro Timchenko
Apr 7 · 10 min read

JDK 16 is the open-source reference implementation of version 16 of the Java SE Platform, as specified by by in the Java Community Process.

JDK 16 reached on 16 March 2021. Production-ready binaries under the GPL are ; binaries from other vendors .

The features and schedule of this release were proposed and tracked via the , as amended by the . The release was produced using the .

If you missed what was changed in Java 15 you can check it here:

Features

JEP 338: Vector API (Incubator) ()

Provides an initial iteration of an incubator module, jdk.incubator.vector, to express vector computations that reliably compile at runtime to optimal vector hardware instructions on supported CPU architectures and thus achieve superior performance to equivalent scalar computations.

provides a mechanism for developers to make it explicit to the compiler that vector operations should be used. This does, however, make the code more complicated. First, it is necessary to obtain a vector species. This is the form of the vector that is required, both in terms of the size of the register to be used and the type of the data to be loaded, such as a float. Type-specific vectors are then created and loaded, as required, with values. The final part is to manipulate the vectors using the appropriate mathematical functions.

JEP 347: Enable C++14 Language Features (in JDK source code)

This allows the use of C++14 language features in JDK C++ source code and gives specific guidance about which of those features may be used in HotSpot code. Through JDK 15, the language features used by in the JDK have been limited to the C++98/03 language standards. It requires updating the minimum acceptable version of various platform compilers.

JEP 357: Migrate from Mercurial to Git

Migrate the OpenJDK Community’s source code repositories from Mercurial (hg) to Git.

Goals

  • Migrate all single-repository OpenJDK Projects from Mercurial to
  • Preserve all version control history, including tags
  • Reformat commit messages according to Git best practices
  • Port the , , and tools to Git
  • Create a tool to translate between Mercurial and Git hashes

JEP 369: Migrate to GitHub

These JEPs migrate the OpenJDK Community’s source code repositories from Mercurial (hg) to Git and host them on GitHub for JDK 11 and later. The migration includes updating tooling such as jcheck, webrev, and defpath tools to Git. reduces the size of the metadata (around ¼ of the size) preserving local disk space and reducing clone time. Modern tooling is better integrated with Git than Mercurial. OpenJDK Git repositories are now

JEP 376: ZGC Concurrent Stack Processing ()

The Z Garbage Collector now processes thread stacks concurrently. This allows all roots in the to be processed by ZGC in a concurrent phase instead of stop-the-world pauses. The amount of work done in ZGC pauses has now become constant and typically not exceeding a few hundred microseconds.

JEP 380: Unix domain sockets ()

Provides support for Unix domain sockets (AF_UNIX) in the java.nio.channels, SocketChannel, and ServerSocketChannel classes.

Now we have the , which provides an easy way to handle interprocess communication on a single host. These sockets are very similar to using a TCP/IP loopback except that they are addressed by a filesystem pathname rather than an IP address and port number. The advantage of UNIX domain sockets is they are more efficient and secure than a loopback.

JEP 386: Alpine Linux Port

Port the JDK to Alpine Linux, and to other Linux distributions that use musl as their primary C library, on both the x64 and AArch64 architectures.

is an implementation, for Linux-based systems, of the standard library functionality described in the ISO C and POSIX standards. Several Linux distributions including and are based on musl, while some others provide an optional musl package (e.g., ).

The Alpine Linux distribution is widely adopted in cloud deployments, microservices, and container environments due to its small image size. A Docker , for example, is less than 6 MB. Enabling Java to run out-of-the-box in such settings will allow Tomcat, Jetty, Spring, and other popular frameworks to work in such environments natively.

JEP 387: Elastic Metaspace ()

This feature returns unused HotSpot VM class-metadata (i.e. metaspace) memory to the operating system more promptly, reducing metaspace footprint. Applications with heavy class loading and unloading activity can accrue a lot of unused space.

The new scheme allocates metaspace memory in smaller chunks, reduces class-loader overhead and fragmentation. It improves elasticity by returning unused metaspace memory to the operating system, which leads to greater application performance and decreases memory utilization.

JEP 388: Windows/AArch64 Port

The focus of these JEPs is not the porting effort itself, which was already done, but integrating them into the JDK mainline repository.

JEP 386 ports the JDK to Alpine Linux and other distributions that use musl as their primary C Library on both x64 and AArch64. In addition, JEP 388 ports the JDK to Windows AArch 64 (ARM64).

JEP 389: Foreign Linker API (Incubator) ()

This incubator API offers statically-typed, pure-Java access to native code. This API will considerably simplify the otherwise convoluted and error-prone process of binding to a native library.

Java has supported native method calls via the Java Native Interface (JNI) since Java 1.1 but it is hard and brittle. s should be able to (mostly) just use any native library that is deemed useful for a particular task. It also provides foreign-function support without the need for any intervening JNI glue code.

JEP 390: Warnings for Value-based Classes ()

This feature designates the primitive wrapper classes (java.lang.Integer, java.lang.Double, etc) as value-based (similar to and ) and add forRemoval to their constructors, which are deprecated since JDK 9, prompting new warnings. It provides warnings about improper attempts to synchronize on instances of any value-based classes in the Java Platform.

Many popular open-source projects have already responded to the deprecation warnings of Java 9 by removing wrapper constructor calls from their sources, and we can expect many more to do so, given the heightened urgency of “deprecated for removal” warnings.

New javac warnings discourage on value-based class instances. Runtime warnings about synchronization can also be activated, using a command-line option -XX:DiagnoseSyncOnValueBasedClasses.

JEP 392: Packaging Tool ()

Provides the jpackage tool, for packaging self-contained Java applications in different formats.

These formats include msi and exe on Windows, pkg and dmg on macOS and deb and rpm on Linux. It also allows launch-time parameters to be specified at packaging time and can be invoked directly, from the command line, or programmatically, via the ToolProvider API.

The jpackage tool was introduced as an incubating tool in JDK 14 by . It remained an incubating tool in JDK 15, to allow time for additional feedback. It has been promoted in JDK 16 from incubation to a production-ready feature. As a consequence of this transition, the name of the jpackage module has changed from jdk.incubator.jpackage to jdk.jpackage.

JEP 393: Foreign-Memory Access API (Third Incubator) ()

First introduced as an incubator API in Java 14 and again in Java 15, this API allows Java programs to safely and efficiently operate on various kinds of foreign memory (e.g., native memory, persistent memory, managed heap memory, etc.). It also provides the foundation for the Foreign Linker API.

JEP 394: Pattern Matching for instanceof ()

First introduced as a preview feature in and again in , Pattern Matching enhances the Java programming language with pattern matching for the instanceof operator.

Pattern matching allows common logic in a program, namely the conditional extraction of components from objects, to be expressed more concisely and safely.

There are two minor changes to how the feature worked in JDK 15. The first is that pattern variables are no longer implicitly final.

The second change is that is now a compile-time error for a pattern to compare an expression of type S against a pattern of type T, where S is a subtype of T.

Here’s an example:

This will result in a compiler error:

Error: pattern type java.util.List is a subtype of expression type java.util.ArrayList<java.lang.String>

JEP 395: Records ()

Also first introduced as a preview feature in and again in , Records provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data. This will significantly reduce the verbosity of these classes and improve code readability and maintainability.

JEP 396: Strongly Encapsulate JDK Internals by Default ()

This feature strongly encapsulates all internal elements of the JDK by default, except for critical internal APIs such as sun.misc.Unsafe. Code successfully compiled with earlier releases that access internal APIs of the JDK may no longer work by default. This change aims to encourage developers to migrate from using internal elements to using standard APIs, so that both they and their users can upgrade without fuss to future Java releases. Strong encapsulation is controlled by the launcher option -–illegal-access, for JDK 9 until JDK 15 defaults to warning, and starting with JDK 16 defaults to deny. It is still possible (for now) to relax encapsulation of all packages with a single command-line option, in the future only opening specific packages with –add-opens will work.

JEP 397: Sealed Classes (Second Preview) ()

Sealed classes and interfaces have been previewed again in JDK 16, initially added to the Java language in JDK 15. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them.

Removed Features and Options

Removal of java.awt.PeerFixer ()

The non-public class java.awt.PeerFixer has been removed in this release. This class was used to provide deserialization support of ScrollPane objects created prior JDK 1.1.1.

Removal of Experimental Features AOT and Graal JIT ()

The Java Ahead-of-Time compilation experimental tool jaotc has been removed. Using defined by produce a not supported option warning but will otherwise be ignored.

The experimental Java-based JIT compiler, Graal , has been removed. Attempting to use it produces a JVMCI error: JVMCI compiler 'graal' not found.

Deprecated Tracing Flags Are Obsolete and Must Be Replaced With Unified Logging Equivalents ()

When Unified Logging was added in Java 9, a number of tracing flags were deprecated and mapped to their unified logging equivalent. These flags are now obsolete and will no longer be converted automatically to enable unified logging. To continue getting the same logging output, you must explicitly replace the use of these flags with their unified logging equivalent.

Obsoleted OptionUnified Logging Replacement-XX:+TraceClassLoading-Xlog:class+load=info-XX:+TraceClassUnloading-Xlog:class+unload=info-XX:+TraceExceptions-Xlog:exceptions=info

Removed Root Certificates with 1024-bit Keys ()

The following root certificates with weak 1024-bit RSA public keys have been removed from the cacerts keystore:

+ alias name "thawtepremiumserverca [jdk]"
Distinguished Name: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
+ alias name "verisignclass2g2ca [jdk]"
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
+ alias name "verisignclass3ca [jdk]"
Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
+ alias name "verisignclass3g2ca [jdk]"
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
+ alias name "verisigntsaca [jdk]"
Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA

Removal of Legacy Elliptic Curves ()

The SunEC provider no longer supports the following elliptic curves that are either obsolete or not implemented using modern formulas and techniques:

secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1

To continue using any of these curves, users must find third-party alternatives.

Conclusion

In this article, we found there is a lot of internal changes were made in Java 16. All these changes could improve the performance of your applications — don’t hesitate to check your app on the latest Java version.

Javarevisited

Medium’s largest Java publication, followed by 10000+ programmers. Follow to join our community.

Sign up for Javarevisited Newsletter

By Javarevisited

Collection of best Java articles, tutorials, courses, books, and resources from Javarevisite and its authors, Java Experts and many more.  

By signing up, you will create a Medium account if you don’t already have one. Review our for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Dmytro Timchenko

Written by

New tech lover. Software developer, like to learn new stuff and share knowledge with the community.

Javarevisited

A humble place to learn Java and Programming better.

Dmytro Timchenko

Written by

New tech lover. Software developer, like to learn new stuff and share knowledge with the community.

Javarevisited

A humble place to learn Java and Programming better.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface.

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox.

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store