After six months of development, Oracle has released the Java SE 16 platform (Java Platform, Standard Edition 16), which uses the open-source project OpenJDK as its reference implementation. Java SE 16 maintains backward compatibility with previous releases of the Java platform, so all previously written Java projects will run without changes on the new version. Installable builds of Java SE 16 (JDK, JRE, and Server JRE) are prepared for Linux (x86_64, AArch64), Windows, and macOS. The reference implementation of Java 16 developed under the OpenJDK project is completely open under the GPLv2 license with exceptions for GNU ClassPath, allowing dynamic linking with commercial products.
Java SE 16 is categorized as a release with a standard support term, with updates being released until the next version. Java SE 11 should be used as a long-term support (LTS) branch, with updates being released until 2026. The next LTS release is scheduled for September 2021. It should be noted that since the release of Java 10, the project has transitioned to a new development process that implies a shorter cycle for new releases. New functionality now develops in one continuously updated master branch that incorporates ready changes, from which branches for stabilizing new releases are created every six months.
In preparing the new release, development has migrated from the Mercurial version control system to Git and the collaborative development platform GitHub. This migration is expected to enhance repository operation performance, increase storage efficiency, provide access to changes throughout the project's history, improve code review support, and utilize APIs for workflow automation. Additionally, the use of Git and GitHub makes the project more appealing to newcomers and developers accustomed to Git.
Among the innovations in Java 16, the following can be noted:
- An experimental module jdk.incubator.vector has been added, featuring the Vector API that provides functions for vector computations executed using the vector instructions of x86_64 and AArch64 processors, allowing simultaneous operations on multiple values (SIMD). Unlike the auto-vectorization capabilities available in the HotSpot JIT compiler for scalar operations, the new API allows explicit control over vectorization for parallel data processing.
- The code in JDK and the HotSpot VM, written in C++, now allows the use of features introduced in the C++14 specification. Previously, only C++98/03 standards were permitted.
- The ZGC (Z Garbage Collector), which operates in a passive mode and minimizes pauses caused by garbage collection as much as possible, has been enhanced to support parallel handling of thread stacks without pausing application threads. Only those operations in ZGC that require suspension and involve persistent delays, typically not exceeding a few hundred microseconds, remain.
- Support for Unix sockets (AF_UNIX) has been added to the SocketChannel, ServerSocketChannel, and java.nio.channels classes.
- A port for the Linux distribution Alpine with the standard musl C library has been implemented, popular in container, microservices, cloud, and embedded system environments. This proposed port enables Java programs to run as standard applications in such environments. Additionally, using jlink, all unused modules can be removed to create a minimal environment sufficient for running the application, allowing for the creation of application-specific compact images.
- An Elastic Metaspace mechanism has been implemented to optimize the allocation and deallocation of memory occupied by class metadata (metaspace) in the HotSpot JVM. The use of Elastic Metaspace reduces memory fragmentation, decreases overhead in the class loader, and positively impacts the performance of long-running server applications by enabling faster release of memory occupied by unused class metadata back to the operating system. An option '–XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)' has been proposed for selecting the memory release mode after class unloading.
- A JDK port has been added for Windows systems running on AArch64 architecture processors.
- A third preview of the Foreign-Memory Access API has been proposed, allowing Java applications to safely and efficiently access memory areas outside the Java heap, using new abstractions such as MemorySegment, MemoryAddress, and MemoryLayout.
- An experimental Foreign Linker API has been implemented, providing access from Java to native code. Along with the Foreign-Memory API, this new interface significantly simplifies the creation of wrappers around regular shared libraries.
- The jpackage utility has been added, allowing the creation of packages for self-contained Java applications. The utility is based on javapackager from JavaFX and enables the formation of packages in formats native to various platforms (msi and exe for Windows, pkg and dmg for macOS, deb and rpm for Linux). Packages include all necessary dependencies.
- Strict encapsulation of all internal JDK elements is now enabled by default, except for critical APIs such as sun.misc.Unsafe. The value of the "--illegal-access" option is now set to "deny" by default instead of "permit", which will block attempts to access most internal classes, methods, and fields from code. To bypass this restriction, use the "--illegal-access=permit" option.
- The implementation of pattern matching in the "instanceof" operator has been stabilized, allowing for immediate definition of a local variable for accessing the validated value. For example, instead of explicitly defining "String s = (String) obj", you can directly write "if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}". Previously: if (obj instanceof Group) { Group group = (Group) obj; var entries = group.getEntries(); } Now you can omit defining "Group group = (Group) obj": if (obj instanceof Group group) { var entries = group.getEntries(); }
- The implementation of the "record" keyword has been stabilized, providing a compact form for defining classes that allows for the omission of explicit definitions of various low-level methods like equals(), hashCode(), and toString() when data is stored only in fields with unchanging behavior. When a class uses type implementations of these methods, it can omit their explicit definitions: public record BankTransaction(LocalDate date, double amount, String description) {}
This declaration will lead to the automatic addition of implementations for the methods equals(), hashCode(), and toString(), along with the constructor and methods that manage data changes (getter).
- A second preliminary proposal of sealed classes and interfaces has been introduced, which cannot be used by other classes and interfaces for inheritance, extension, or implementation overriding. Sealed classes also provide a more declarative way to restrict the use of a superclass than access modifiers, based on explicitly listing the subclasses allowed for extension. package com.example.geometry; public sealed class Shape permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {…}
Source: opennet.ru
