What’s coming in Java 16
Java 16 is scheduled to be released on March 16. Here is a look at what changes you can expect in the release.
Foojay announces initial companies for the advisory board.
Foojay is a community site for Java and OpenJDK developers. Azul, Datadog, DataStax, JFrog, Payara, and Snyk are the initial companies that will be a part of the advisory board.
According to Foojay, the board will guide the direction, content, and oversight of the Foojay.io site. It will also work toward growing the community and continuing to meet Foojay’s mission of providing free information to Java developers.
“Foojay is an example of the strength and longevity of the Java community that is greater than any single company,” said Stephen Chin, vice president of developer relations at JFrog. “It is composed of active, passionate, and caring individuals who want to share their expertise and help mentor the next generation of developers. We’re excited to be part of the conversation and help the community leverage modern CI/CD and cloud-native technology for our beloved Java.”
JEP 338: Vector API (Incubator)
This Java Enhancement Proposal (JEP) will provide an initial iteration of an incubator module that can express vector calculations that are compiled at runtime. This module will be clear and concise, platform-agnostic, have reliable runtime compilation and performance on x64 and AArch64 architectures, and offer graceful degradation when a vector computation cannot be fully expressed, the OpenJDK team explained.
JEP 347: Enable C++14 Language Features
The goal of this addition is to support C++14 language features and give specific guidance on which features can be used in HotSpot code.
JEP 357: Migrate from Mercurial to Git
This JEP relates to the goal of migrating the OpenJDK Community’s source code repositories from Mercurial to Git.
JEP 369: Migrate to GitHub
Similar to JEP 357, this relates to the goal of hosting the Open- JDK Community’s Git repositories on GitHub. All single-repository OpenJDK projects, including JDK feature releases and JDK update releases for versions 11 and later, will be migrated.
JEP 376: ZGC: Concurrent Thread-Stack Processing
This will remove thread-stack processing from ZGC safepoints; make stack processing lazy, cooperative, concurrent, and incremental; remove per-thread root processing from ZGC safepoints, and provide a mechanism for HotSpot subsystems to lazily process stacks, according to OpenJDK.
JEP 380: Unix-domain Socket Channels
Unix-domain sockets are used for inter-process communication, and are similar to TCP/IP sockets, except they are addressed by filesystem pathnames instead of IP addresses and port numbers. It is intended for Java to support all Unix-domain socket features common across major Unix platforms and Windows.
JEP 386: Alpine Linux Port
The goal of this JEP is to port the JDK to Alpine Linux and other Linux distributions that use musl as their primary C library. Musl is an implementation, for Linux-based systems, of the standard library functionality described in the ISO C and POSIX standards. Several Linux distributions including Alpine Linux and OpenWrt are based on musl, while some others provide an optional musl package (e.g., Arch Linux).
JEP 387: Elastic Metaspace
According to OpenJDK, Metaspace has been notorious for using a lot of off-heap memory, so the goal of this feature is to return unused HotSpot class-metadata to the operating system, reduce metaspace footprint, and simplify metaspace code to reduce maintenance costs.
JEP 388: Windows/AArch64 Port
The JDK will complete its port to Windows/AArch64. The focus of this JEP is not the porting effort itself, which is mostly complete, but rather the integration of the port into the JDK main-line repository.
JEP 389: Foreign Linker API (Incubator)
Java will introduce an API that offers “statically-typed, pure- Java access to native code.” In combination with the Foreign- Memory API, this will simplify the process of binding to a native library, which is an error-prone process.
JEP 390: Warnings for Value-Based Classes
This feature will designate primitive wrapper classes as value-based. It will also deprecate their constructors for removal, which will launch new deprecation warnings.
JEP 392: Packaging Tool
The new jpackage tool can be used to package Java applications.
JEP 393: Foreign-Memory Access API (Third Incubator)
This API enables applications to safely access foreign memory that is outside the Java heap. It was created because many Java applications access foreign memory, but the Java API doesn’t have an efficient or safe way of accessing foreign memory.
JEP 394: Pattern Matching for instanceof
The goal of this feature is to enhance the pattern matching capability on the instanceof operator. According to the OpenJDK team, pattern matching allows common logic to be expressed concisely and safely. This feature was also was previewed in both JDK 14 and JDK 15. It would be finalized in JDK 16. 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
Records are classes that can act as “transparent carriers for immutable data,” the OpenJDK team explained. They can be helpful with modeling data aggregates. Records can be considered nominal tuples. Records were 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. The goals of the plan include devising an object-oriented construct that expresses a simple aggregation of values, 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.
JEP 396: Strongly Encapsulate JDK Internals by Default
According to the team, this change will encapsulate internal elements by default, except for critical internal APIs like sun.misc.Unsafe. The motivation behind this strong encapsulation is that developers of libraries, frameworks, and tools often use internal elements in ways that compromise security and maintainability. Strong encapsulation ensures that code outside of a module can only access public and protected elements of a package and that protected elements can only be accessed from subclasses of their defining classes.
JEP 397: Sealed Classes (Second Preview)
Sealed classes restrict which other classes extend or implement them. They will allow the author of a class to control what code can be used to implement it, provide a more declarative way of restricting access, and support future directions in pattern matching.
REFERENCES: https://openjdk.java.net/projects/jdk/16/
