The Arrival of Java 16!

Follow OpenJDK on Twitter

2020 proved to be a memorable year for Java as we celebrated its 25th birthday. With over two decades of innovation, Java has continued to be:

  • Flexible by adapting to the changing technology landscape while remaining platform independent.
  • Reliable by retaining backwards compatibility.
  • Performant by accelerating innovation without sacrificing security.

Coupled with Java’s ability to boost performance, stability and security of the platform along the way, it continues to be the world’s most popular programming language among developers. According to IDC’s latest report “Java Turns 25”, over nine million developers representing 69% of full-time developers worldwide use Java – more than any other language.

Further demonstrating Java’s path of continued innovation, Oracle is proud to announce the general availability of Java 16 representing the seventh feature release as part of the six-month cadence. This level of predictability allows developers to more easily manage their adoption of innovation thanks to a steady stream of expected changes.

Chart showing number of features per release since Java 8

Java 16 is now available!

Oracle now offers Java 16 for all developers and enterprises. Oracle JDK 16 will receive a minimum of two quarterly updates, per the Oracle Critical Patch Update (CPU) schedule, before being followed by Oracle JDK 17. Java 17 will reach general availability on September 2021, but early access builds are already being offered at

Once again, Oracle provides Java 16 as the Oracle OpenJDK release using the open source GNU General Public License v2, with the Classpath Exception (GPLv2+CPE), and also under a commercial license for those using the Oracle JDK release as part of an Oracle product or service, or for those who want to be able to get commercial support.

Java 16, Together

Similar to previous releases, we continue to celebrate the contributions made to Java 16 from many individuals and organizations in the OpenJDK Community — we all build Java, together!

JDK 16 Fix Ratio

The overall rate of change over time in the JDK has remained essentially constant for many years, but under the six-month cadence the pace at which production-ready innovations are delivered has vastly improved.

Instead of making tens of thousands of fixes and around one hundred JDK Enhancement Proposals (JEPs) available in a large major release every few years, enhancements are delivered in smaller Feature releases on a more manageable, predictable six-month schedule. These changes can range from a significant feature to small enhancements to routine maintenance, bug fixes, and documentation improvements. Each change is represented in a single commit for a single issue in the JDK Bug System.

Of the 1,897 issues marked as fixed in Java 16, 1,397 were completed by people working for Oracle while 500 were contributed by individual developers and developers working for other organizations. Going through the issues and collating the organization data from assignees results in the following chart of organizations sponsoring the development of fixes in Java 16:

Graph showing the number of fixes per organization

Oracle would like to thank the developers working for organizations, like ARM, SAP, Red Hat and Tencent for their notable contributions. We are also thankful to see contributions from smaller organizations such as Ampere Computing, Bellsoft, DataDog, Microdoc and independent developers who collectively contributed 3% of the fixes in Java 16.

We are equally grateful to the many experienced developers who reviewed proposed changes, the early adopters who tried out early access builds and reported issues, and the dedicated professionals who provided feedback on the OpenJDK mailing lists.

The following individuals provided invaluable feedback on build quality, logged good quality bugs or offered frequent updates:

  • Jaikiran Pai (Apache Ant)
  • Gary Gregory (Apache Commons)
  • Uwe Schindler (Apache Lucene)
  • Robert Scholte (Apache Maven)
  • Mark Thomas (Apache Tomcat)
  • Enrico Olivelli (Apache Zookeeper)
  • Rafale Winterhalter (Byte Buddy)
  • Peter Karich (Graph Hopper)
  • Evgeny Mandikov (JaCoCo)
  • Marc Hoffman (JaCoCo)
  • Vincent Privat (JOSM)
  • Christian Stein (JUnit 5)
  • David Karnok (RxJava)

Additionally, through the Quality Outreach program we would like to thank the following FOSS projects and individuals who provided excellent feedback on testing Java 16 early access builds to help improve the quality of the release.

  • Apache Ant
  • Apache Derby (Rich Hillegas)
  • Apache Lucene
  • Apache Maven
  • Apache Tomcat
  • Apache Wicket (Martin Grigorov)
  • Apache ZooKeeper
  • Eclipse Collections (Nikhil Nanivadekar)
  • eo-yaml (Mihai Andronache)
  • FXGL (Almas Baimagambetov)
  • FXyz (Sean Phillips)
  • Java Katas (Chandra Guntur)
  • GraphHopper
  • Hibernate ORM
  • Hibernate Validator
  • Hibernate Search
  • Hibernate Reactive (Sanne Grinovero & Yoann Rodiere)
  • JobRunr (Ronald Dehuysser)
  • jOOQ (Lukas Eder)
  • MyBatis (Iwao Ave)
  • Micrometer (Tommy Ludwig)
  • RxJava
  • Sejda
  • PDFsam (Andrea Vacondio)

New in Java 16

Along with thousands of performance, stability and security updates, Java 16 offers users seventeen main enhancements/changes (known as JDK Enhancement Proposals - JEPs), including three incubator modules and one preview feature.

Some enhancements are introduced in Incubator Modules, a means of putting non-final APIs and non-final tools in the hands of developers that allows users to offer feedback that can ultimately improve the quality of the Java platform.

Similarly, some enhancements are introduced as Preview Features, language or VM features of the Java SE Platform that are fully specified, fully implemented, and yet impermanent. They are made available in JDK feature releases to provoke developer feedback based on real-world use, which may lead to them becoming permanent in a future release. This offers users the chance to provide timely feedback, as well as allowing tool vendors the opportunity to build support for the feature before the bulk of Java developers use it in production.

The 17 JEPs delivered with Java 16 have been grouped into six different categories:

New Language Features

JEP 394 Pattern Matching for instanceof

First introduced as a preview feature in Java 14 and again in Java 15, 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.

JEP 395 Records

Also first introduced as a preview feature in Java 14 and again in Java 15, 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.

JVM Improvements

JEP 376 ZGC Concurrent Thread Processing

JEP 376 move ZGC thread-stack processing from safepoints to a concurrent phase, allows sub-millisecond pauses inside GC safepoints, even on large heaps. Removing the final source of latency in the ZGC Garbage collector will greatly improve performance and efficiency of applications in this and subsequent releases.

JEP 387 Elastic Metaspace

This feature returns unused HotSpot 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.

New Tools and Libraries

JEP 380 Unix-Domain Socket Channels

Unix-domain sockets have long been a feature of most Unix platforms, and are now supported in Windows 10 and Windows Server 2019. This feature adds Unix-domain (AF_UNIX) socket support to the socket channel and server-socket channel APIs in the java.nio.channels package. It extends the inherited channel mechanism to support Unix-domain socket channels and server socket channels. Unix-domain sockets are used for inter-process communication (IPC) on the same host. They are similar to TCP/IP sockets in most respects, except that they are addressed by filesystem path names rather than Internet Protocol (IP) addresses and port numbers. For local, inter-process communication, Unix-domain sockets are both more secure and more efficient than TCP/IP loopback connections.

JEP 392 Packaging Tool

This feature was first introduced as an incubator module in Java 14. This tool allows for packaging self-contained Java applications. It supports native packaging formats to give end users a natural installation experience. 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. Note that the name of the jpackage module changes from jdk.incubator.jpackage to jdk.jpackage. This will improve the end-user experience when installing applications and simplify deployments using the “app store” model.

Futureproofing Your Work

JEP 390 Warning for Value-Based Classes

This feature designates the primitive wrapper classes (java.lang.Integer, java.lang.Double, etc.) as value-based (similar to java.util.Optional and java.time.LocalDateTime) 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.

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 accesses 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.

Incubator and Preview Features

JEP 338 Vector API (Incubator)

This incubator API provides an initial iteration of an API 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. It allows taking advantage of the Single Instruction Multiple Data (SIMD) instructions available on most modern CPUs. Although HotSpot supports auto-vectorization, the set of transformable scalar operations is limited and fragile to changes in the code. This API will allow developers to easily write portable and performant vector algorithms in Java.

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. Java developers 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 393 Foreign Memory Access API (3rd 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 397 Sealed Classes (2nd Preview)

This preview feature restricts which other classes or interfaces may extend or implement them. It allows the author of a class or interface to control which code is responsible for implementing it. Also, it provides a more declarative way than access modifiers to restrict the use of a superclass. And, it supports future directions in pattern matching by underpinning the exhaustive analysis of patterns.

Improving Productivity for OpenJDK Developers

The rest of the changes are not directly visible to Java developers (those that use Java to code and run applications), rather only to developers of Java (those that work on OpenJDK).

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 C++ code 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, 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. 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 at

JEP 386 Alpine Linux Port, 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 main-line 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).

Tooling Support

Current tooling support helps drive developer productivity. With Java 16, we continue to welcome the efforts of leading IDE vendors whose tooling solutions offer developers support for current Java versions. Developers can expect to receive Java 16 support with the following IDEs:

Java continues to be the #1 programming language of choice by software programmers. As the on-time delivery of improvements with Java 16 demonstrates, through continued thoughtful planning and ecosystem involvement, the Java platform is well-positioned for modern development and growth in the cloud.

Continue staying current with news and updates by:

  • Visiting Inside.Java (news and views by the Java Team at Oracle)
  • Listening to the Inside.Java podcasts (a show for Java Developers brought to you directly from the people that make Java at Oracle. We’ll discuss the language, the JVM, OpenJDK, platform security, innovation projects like Loom and Panama, and everything in between).
  • Joining the OpenJDK mailing lists (the place to learn about the progress of your favorite OpenJDK projects).