ProHoster > Blog > internet news > Java SE 16 release

Java SE 16 release

After six months of development, Oracle has released Java SE 16 (Java Platform, Standard Edition 16), which uses the OpenJDK open source project as a reference implementation. Java SE 16 maintains backward compatibility with previous releases of the Java platform, and all previously written Java projects will work without changes when running under the new version. Ready-to-install builds of Java SE 16 (JDK, JRE, and Server JRE) are prepared for Linux (x86_64, AArch64), Windows, and macOS. Developed by the OpenJDK project, the Java 16 reference implementation is fully open source under the GPLv2 license with GNU ClassPath exceptions to allow dynamic linking to commercial products.

Java SE 16 is categorized as a regular support release, with updates to be released before the next release. The long term support (LTS) branch should be Java SE 11, which will receive updates until 2026. The next LTS release is scheduled for September 2021. Recall that starting with the release of Java 10, the project switched to a new development process, which implies a shorter cycle for the formation of new releases. New functionality is now being developed in one constantly updated master branch, which incorporates already completed changes and from which branches are branched every six months to stabilize new releases.

In preparation for the new release, development has shifted from Mercurial source control to Git and the GitHub collaborative development platform. The migration is expected to improve the performance of repository operations, increase storage efficiency, provide access to changes throughout the history of the project, improve support for code reviews, and use APIs to automate workflows. In addition, the use of Git and GitHub makes the project more attractive for beginners and developers who are used to Git.

New features in Java 16 include:

  • An experimental jdk.incubator.vector module has been added with the implementation of the Vector API, which provides functions for vector calculations that are performed using the vector instructions of the x86_64 and AArch64 processors and allow you to simultaneously apply operations to several values ​​\uXNUMXb\uXNUMXb(SIMD). In contrast to the autovectorization of scalar operations provided in the HotSpot JIT compiler, the new API allows you to explicitly control vectorization for parallel data processing.
  • JDK and HotSpot VM code written in C++ is allowed to use features introduced in the C++14 specification. Previously, C++98/03 standards were allowed.
  • The ZGC (Z Garbage Collector) garbage collector, which works in passive mode and minimizes delays due to garbage collection as much as possible, has been added the ability to process stacks of threads in parallel without suspending the execution of application threads. ZGC now only has paused jobs that have constant delays, typically no more than a few hundred microseconds.
  • Support for Unix sockets (AF_UNIX) has been added to the SocketChannel, ServerSocketChannel, and java.nio.channels classes.
  • Implemented a port for the Alpine Linux distribution with the standard musl C library, which is popular in environments for containers, microservices, cloud and embedded systems. The proposed port in such environments allows you to run Java programs as normal applications. In addition, with jlink, you can remove all unused modules and create a minimal environment sufficient to run the application, which allows you to create application-specific compact images.
  • The Elastic Metaspace mechanism has been implemented, which optimizes the operations of allocating and returning memory occupied by class metadata (metaspace) in the HotSpot JVM. The use of Elastic Metaspace reduces memory fragmentation, reduces class loader overhead, and also improves the performance of long-running server applications by quickly returning to the operating system the memory occupied by unused class metadata. The "-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)" option is proposed to select the mode of memory release after class unloading.
  • Added a JDK port for Windows systems running on AArch64-based hardware.
  • A third preview of the Foreign-Memory Access API has been proposed that allows Java applications to safely and efficiently access areas of memory outside the Java heap by manipulating the new MemorySegment, MemoryAddress, and MemoryLayout abstractions.
  • An experimental Foreign Linker API has been implemented, providing access from Java to native code. Together with the Foreign-Memory API, the new API greatly simplifies the creation of bindings over conventional shared libraries.
  • Added jpackage utility to create packages for self-contained Java applications. The utility is based on javapackager from JavaFX and allows you to generate packages in formats native to various platforms (msi and exe for Windows, pkg and dmg for macOS, deb and rpm for Linux). The packages include all required dependencies.
  • Strict encapsulation of all JDK internals is 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 the code. To bypass the restriction, use the "--illegal-access=permit" option.
  • The implementation of pattern matching in the "instanceof" operator has been stabilized, which allows you to immediately define a local variable to refer to the checked value. For example, you can immediately write "if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}" without explicitly defining "String s = (String) obj". It was: if (obj instanceof Group) { Group group = (Group) obj; var entries = group.getEntries(); } Now we can do without the definition of "Group group = (Group) obj": if (obj instanceof Group group) { var entries = group.getEntries(); }
  • Stabilized the implementation of the "record" keyword, which provides a compact form for class definitions, eliminating the need to explicitly define various low-level methods such as equals(), hashCode() and toString(), in cases where data is stored only in fields, behavior with which it does not change. When a class uses generic implementations of the equals(), hashCode(), and toString() methods, it can do without explicitly defining them: public record BankTransaction(LocalDate date, double amount, String description) {}

    This declaration will automatically add implementations of the equals(), hashCode() and toString() methods in addition to the constructor and getter methods.

  • A second draft of "sealed" classes and interfaces is proposed that cannot be used by other classes and interfaces to inherit, extend, or override implementations. Sealed classes also provide a more declarative way of restricting the use of a superclass than access modifiers, based on an explicit enumeration of the subclasses allowed to be extended. 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

Add a comment