Java Development Kit (JDK) 16 has just added three proposed new features, including a production-ready package tool and records capabilities proposed in late-October. Previously proposed features include 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.

New capabilities for JDK 16 in the proposed-to-target stage as of October 26, 2020, include:

  • Providing the jpackage tool for packaging self-contained Java applications. Introduced as an incubating tool in JDK 14, jpackage remained in incubation in JDK 15. With JDK 16, jpackage moves to production, supporting native package formats to give users a natural installation experience and allow launch-time parameters to be specified at packaging time. It can be invoked directly from the command line or programmatically. The new packaging tool addresses a situation in which many Java applications need to be installed on native platforms in a first-class way, rather than being placed on the class path or module path. An installable package suitable for the native platform is needed.
  • Providing records classes that act as transparent carriers for immutable data. Records can be considered nominal tuples. Records was previewed in JDK 14 and JDK 15. This effort is in response to complaints that Java has been too verbose or has too much ceremony. Goals of the plan include devising an object-oriented construct that expresses a simple aggregation of value, helping developers focus on modeling immutable data rather than extensible behavior, automatically implementing data-driven methods such as equals and accessors, and preserving longstanding Java principles such as nominal typing.
  • The addition of Unix-domain socket channels, in which Unix-domain (AF_UNIX) socket support is added to the socket channel and server socket channel APIs in the nio.channels package. The plan also extends the inherited channel mechanism to support Unix-domain socket channels and server socket channels. Unix-domain sockets are used for inter-process communications 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 IP addresses and port numbers. The goal of the new capability is to support all features of Unix-domain socket channels that are common across major Unix platforms and Windows. Unix-domain socket channels will behave the same as existing TCP/IP channels in terms of read/write behavior, connection setup, acceptance of incoming connections by servers, and multiplexing with other non-blocking selectable channels in a selector. Unix-domain sockets are more secure and more efficient than TCP/IP loopback connections for local, inter-process communications.

Eight proposals officially target JDK 16 as of October 26, 2020. The new capabilities coming to Java 16 include:

  • 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.
  • An elastic metaspace capability, which returns unused HotSpot VM class metadata (metaspace) memory more promptly to the OS, reduces metaspace footprint and simplifies metaspace code to reduce maintenance costs. Metaspace has had issues with high off-heap memory use. The plan calls for replacing the existing memory allocator with a buddy-based allocation scheme, providing an algorithm to divide memory into partitions to satisfy memory requests. This approach has been used in places such as the Linux kernel and will make it practical to allocate memory in smaller chunks to reduce class-loader overhead. Fragmentation also will be reduced. In addition, the commitment of memory from the OS to memory management arenas will be done lazily, on demand, to reduce the footprint for loaders that start out with large arenas but do not use them immediately or might not use them to their full extent. To fully exploit the elasticity offered by buddy allocation, metaspace memory will be arranged into uniformly sized granules that can be committed and uncommitted independently of each other.
  • Enablement of C++ 14 language features, to allow the use of C++ 14 capabilities in JDK C++ source code and give specific guidance about which of these features may be used in HotSpot VM code. Through JDK 15, language features used by C++ code in the JDK have been limited to the C++98/03 language standards. With JDK 11, the source code was updated to support building with newer versions of the C++ standard. This includes being able to build with recent versions of compilers that support C++ 11/14 language features. This proposal does not propose any style or usage changes for C++ code that is used outside of HotSpot. But to take advantage of C++ language features, some build-time changes are required, depending on the platform compiler.
  • A vector API in an incubator stage, in which the JDK would be fitted with an incubator module, jdk.incubator.vector, to express vector computations that compile to optimal vector hardware instructions on supported CPU architectures, to achieve superior performance to equivalent scalar computations. The vector API provides a mechanism to write complex vector algorithms in Java, using pre-existing support in the HotSpot VM for vectorization but with a user model that makes vectorization more predictable and robust. Goals of the proposal include providing a clear and concise API to express a range of vector computations, being platform-agnostic by supporting multiple CPU architectures, and offering reliable runtime compilation and performance on x64 and AArch64 architectures. Graceful degradation also is a goal, in which a vector computation would degrade gracefully and still function if it cannot be fully expressed at runtime as a sequence of hardware vector instructions, either because an architecture does not support some instructions or another CPU architecture is not supported.
  • Porting the JDK to the Windows/AArch64 platform. With the release of new server-class and consumer AArch64 (ARM64) hardware, Windows/AArch64 has become an important platform due to demand. While the porting itself is already mostly complete, the focus of this proposal involves integration of the port into the mainline JDK repository.
  • Porting of the JDK to Alpine Linux and to other Linux distributions that use musl as their primary C library, on x64 and AArch64 architectures. Musl is a Linux implementation of the standard library functionality described in the ISO C and Posix standards. Alpine Linux is widely adopted in cloud deployments, microservices, and container environments due to its small image size. A Docker image for Linux is smaller than 6MB. Letting Java run out-of-the-box in such settings will allow Tomcat, Jetty, Spring, and other popular frameworks to work in these environments natively. By using jlink to reduce the size of the Java runtime, a user can create an even smaller image tailored to run a specific application.
  • Migration of OpenJDK source code repositories from Mercurial to Git. Driving this effort are advantages in version control system metadata size and available tools and hosting.
  • Migration to GitHub, related to the Mercurial-to-Git migration, with JDK 16 source code repositories to be on the popular code-sharing site. The transition to Git, GitHub, and Skara for the Mercurial JDK and JDK-sandbox was done on September 5 and is open for contributions.  

Early-access builds of JDK 16 for Linux, Windows, and MacOS can be found at jdk.java.net. Like JDK 15, JDK 16 will be a short-term release, supported for six months. JDK 17, due in September 2021, will be a long-term support (LTS) release that will receive several years of support. The current LTS release, JDK 11, was released in September 2018.

Copyright © 2020 IDG Communications, Inc.

Leave a Reply

Your email address will not be published. Required fields are marked *

**************