JDK 16: The new features in Java 16

Java Development Kit (JDK) 16 has added two more proposed new features including strong encapsulation of JDK internals and a foreign linker API. Previously proposed features include a foreign-memory access API, pattern matching, a production-ready package tool, concurrent thread-stack processing for garbage collection, support for C++ 14 language features, and an “elastic metaspace” capability to more quickly return unused class metadata memory to the OS.JDK 16 will be the reference implementation of the version of standard Java set to follow JDK 15, which arrived September 15. A proposed release schedule has JDK 16 reaching rampdown phases on December 10 and January 14, 2021, followed by release candidates arriving February 4 and February 18, 2021. The production release is slated to be published March 16, 2021.To read this article in full, please click here

JDK 16: The new features in Java 16

Java Development Kit (JDK) 16 has added two more proposed new features including strong encapsulation of JDK internals and a foreign linker API. Previously proposed features include a foreign-memory access API, pattern matching, a production-ready package tool, concurrent thread-stack processing for garbage collection, support for C++ 14 language features, and an “elastic metaspace” capability to more quickly return unused class metadata memory to the OS.

JDK 16 will be the reference implementation of the version of standard Java set to follow JDK 15, which arrived September 15. A proposed release schedule has JDK 16 reaching rampdown phases on December 10 and January 14, 2021, followed by release candidates arriving February 4 and February 18, 2021. The production release is slated to be published March 16, 2021.

Fourteen proposals officially target JDK 16 as of November 23, 2020, while strong encapsulation of JDK internals remains in the “proposed for targeting” phase. The new capabilities coming to Java 16 include:

  • Strong encapsulation of JDK internals by default, except for critical internal APIs such as misc.Unsafe. Users can choose the relaxed strong encapsulation that has been the default since JDK 9. Goals of this proposal include improving the security and maintainability of the JDK, as part of Project Jigsaw, and encouraging developers to migrate from using internal elements to using standard APIs so that both developers and end users can update easily to future Java releases. This proposal does carry a primary risk that existing Java code will fail to run. Developers are encouraged to use the jdeps tool to identify code that depends on internal elements of the JDK and switch to standard replacements when available. Developers can use an existing release, such as JDK 11, to test existing code by using --illegal-access=warn to identify internal elements accessed via reflection, using --illegal-access=debug to pinpoint errant code, and testing with --illegal-access=deny.
  • Foreign linker API, offering statically typed, pure-Java access to native code. This API will be in an incubator stage in JDK 16. Together with the proposed foreign-memory access API, the foreign linker API will considerably simplify the otherwise error-prone process of binding to a native library. This plan is intended to replace JNI (Java Native Interface) with a superior pure-Java development model, to offer C support, and, over time, to be flexible enough to accommodate support for other platforms, such as 32-bit x86, and foreign functions written in languages other than C, such as C++. Performance should be better than or comparable to JNI.
  • Moving ZGC (Z Garbage Collector) thread-stack processing from safepoints to a concurrent phase. Goals of this plan include removing thread-stack processing from ZGC safepoints; making stack processing lazy, cooperative, concurrent, and incremental; removing all other per-thread root processing from ZGC safepoints; and providing a mechanism for other HotSpot VM subsystems to lazily process stacks. ZGC is intended to make GC pauses and scalability issues in HotSpot a thing of the past. So far, GC operations that scale with the size of the heap and the size of metaspace have been moved out of safepoint operations and into concurrent phases. These have included marking, relocation, reference processing, class unloading, and most root processing. The only activities still done in GC safepoints are a subset of root processing and a time-bounded marking termination operation. These roots have included Java thread stacks and other thread roots, with these roots being problematic because they scale with the number of threads. To move beyond the current situation, per-thread processing, including stack scanning, must be moved to a concurrent phase. With this plan, the throughput cost of the improved latency should be insignificant and the time spent inside ZGC safepoints on typical machines should be less than one millisecond.