JDK 16 is the open-source reference implementation of version 16 of the Java SE Platform, as specified by by JSR 390 in the Java Community Process.
If you missed what was changed in Java 15 you can check it here:
What’s new in Java 15
In this article, we will check what was added and removed in Java 15.
- 338:Vector API (Incubator)
- 347:Enable C++14 Language Features
- 357:Migrate from Mercurial to Git
- 369:Migrate to GitHub
- 376:ZGC: Concurrent Thread-Stack Processing
- 380:Unix-Domain Socket Channels
- 386:Alpine Linux Port
- 387:Elastic Metaspace
- 388:Windows/AArch64 Port
- 389:Foreign Linker API (Incubator)
- 390:Warnings for Value-Based Classes
- 392:Packaging Tool
- 393:Foreign-Memory Access API (Third Incubator)
- 394:Pattern Matching for instanceof
- 396:Strongly Encapsulate JDK Internals by Default
- 397:Sealed Classes (Second Preview)
JEP 338: Vector API (Incubator) (JDK-8201271)
Provides an initial iteration of an incubator module,
jdk.incubator.vector, to express vector computations that reliably compile at runtime to optimal vector hardware instructions on supported CPU architectures and thus achieve superior performance to equivalent scalar computations.
The vector API provides a mechanism for developers to make it explicit to the compiler that vector operations should be used. This does, however, make the code more complicated. First, it is necessary to obtain a vector species. This is the form of the vector that is required, both in terms of the size of the register to be used and the type of the data to be loaded, such as a float. Type-specific vectors are then created and loaded, as required, with values. The final part is to manipulate the vectors using the appropriate mathematical functions.
JEP 347: Enable C++14 Language Features (in JDK source code)
This allows the use of C++14 language features in JDK C++ source code and gives specific guidance about which of those features may be used in HotSpot code. Through JDK 15, the language features used by C++ code in the JDK have been limited to the C++98/03 language standards. It requires updating the minimum acceptable version of various platform compilers.
JEP 357: Migrate from Mercurial to Git
Migrate the OpenJDK Community’s source code repositories from Mercurial (hg) to Git.
- Migrate all single-repository OpenJDK Projects from Mercurial to Git
- Preserve all version control history, including tags
- Reformat commit messages according to Git best practices
- Port the jcheck, webrev, and defpath tools to Git
- Create a tool to translate between Mercurial and Git hashes
JEP 369: Migrate to GitHub
These JEPs migrate the OpenJDK Community’s source code repositories from Mercurial (hg) to Git and host them on GitHub for JDK 11 and later. The migration includes updating tooling such as jcheck, webrev, and defpath tools to Git. Git reduces the size of the metadata (around ¼ of the size) preserving local disk space and reducing clone time. Modern tooling is better integrated with Git than Mercurial. OpenJDK Git repositories are now
JEP 376: ZGC Concurrent Stack Processing (JDK-8239600)
The Z Garbage Collector now processes thread stacks concurrently. This allows all roots in the JVM to be processed by ZGC in a concurrent phase instead of stop-the-world pauses. The amount of work done in ZGC pauses has now become constant and typically not exceeding a few hundred microseconds.
JEP 380: Unix domain sockets (JDK-8238588)
Provides support for Unix domain sockets (AF_UNIX) in the
Now we have the UNIX domain sockets API, which provides an easy way to handle interprocess communication on a single host. These sockets are very similar to using a TCP/IP loopback except that they are addressed by a filesystem pathname rather than an IP address and port number. The advantage of UNIX domain sockets is they are more efficient and secure than a loopback.
JEP 386: Alpine Linux Port
Port the JDK to Alpine Linux, and to other Linux distributions that use musl as their primary C library, on both the x64 and AArch64 architectures.
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).
The Alpine Linux distribution is widely adopted in cloud deployments, microservices, and container environments due to its small image size. A Docker base image for Alpine Linux, for example, is less than 6 MB. Enabling Java to run out-of-the-box in such settings will allow Tomcat, Jetty, Spring, and other popular frameworks to work in such environments natively.
JEP 387: Elastic Metaspace (JDK-8251158)
This feature returns unused HotSpot VM class-metadata (i.e. metaspace) memory to the operating system more promptly, reducing metaspace footprint. Applications with heavy class loading and unloading activity can accrue a lot of unused space.
The new scheme allocates metaspace memory in smaller chunks, reduces class-loader overhead and fragmentation. It improves elasticity by returning unused metaspace memory to the operating system, which leads to greater application performance and decreases memory utilization.
JEP 388: Windows/AArch64 Port
The focus of these JEPs is not the porting effort itself, which was already done, but integrating them into the JDK mainline repository.
JEP 386 ports the JDK to Alpine Linux and other distributions that use musl as their primary C Library on both x64 and AArch64. In addition, JEP 388 ports the JDK to Windows AArch 64 (ARM64).
JEP 389: Foreign Linker API (Incubator) (JDK-8249755)
This incubator API offers statically-typed, pure-Java access to native code. This API will considerably simplify the otherwise convoluted and error-prone process of binding to a native library.
Java has supported native method calls via the Java Native Interface (JNI) since Java 1.1 but it is hard and brittle. Java developers should be able to (mostly) just use any native library that is deemed useful for a particular task. It also provides foreign-function support without the need for any intervening JNI glue code.
JEP 390: Warnings for Value-based Classes (JDK-8249100)
This feature designates the primitive wrapper classes (java.lang.Integer, java.lang.Double, etc) as value-based (similar to java.util.Optional and java.time.LocalDateTime) and add forRemoval to their constructors, which are deprecated since JDK 9, prompting new warnings. It provides warnings about improper attempts to synchronize on instances of any value-based classes in the Java Platform.
Many popular open-source projects have already responded to the deprecation warnings of Java 9 by removing wrapper constructor calls from their sources, and we can expect many more to do so, given the heightened urgency of “deprecated for removal” warnings.
javac warnings discourage synchronization on value-based class instances. Runtime warnings about synchronization can also be activated, using a command-line option
JEP 392: Packaging Tool (JDK-8247768)
jpackage tool, for packaging self-contained Java applications in different formats.
These formats include msi and exe on Windows, pkg and dmg on macOS and deb and rpm on Linux. It also allows launch-time parameters to be specified at packaging time and can be invoked directly, from the command line, or programmatically, via the ToolProvider API.
jpackage tool was introduced as an incubating tool in JDK 14 by JEP 343. It remained an incubating tool in JDK 15, to allow time for additional feedback. It has been promoted in JDK 16 from incubation to a production-ready feature. As a consequence of this transition, the name of the
jpackage module has changed from
JEP 393: Foreign-Memory Access API (Third Incubator) (JDK-8253415)
First introduced as an incubator API in Java 14 and again in Java 15, this API allows Java programs to safely and efficiently operate on various kinds of foreign memory (e.g., native memory, persistent memory, managed heap memory, etc.). It also provides the foundation for the Foreign Linker API.
JEP 394: Pattern Matching for instanceof (JDK-8250623)
Pattern matching allows common logic in a program, namely the conditional extraction of components from objects, to be expressed more concisely and safely.
There are two minor changes to how the feature worked in JDK 15. The first is that pattern variables are no longer implicitly final.
The second change is that is now a compile-time error for a pattern instanceof expression to compare an expression of type S against a pattern of type T, where S is a subtype of T.
Here’s an example:
This will result in a compiler error:
Error: pattern type java.util.List is a subtype of expression type java.util.ArrayList<java.lang.String>
JEP 395: Records (JDK-8246771)
Also first introduced as a preview feature in Java 14 and again in Java 15, Records provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data. This will significantly reduce the verbosity of these classes and improve code readability and maintainability.
JEP 396: Strongly Encapsulate JDK Internals by Default (JDK-8256299)
This feature strongly encapsulates all internal elements of the JDK by default, except for critical internal APIs such as sun.misc.Unsafe. Code successfully compiled with earlier releases that access internal APIs of the JDK may no longer work by default. This change aims to encourage developers to migrate from using internal elements to using standard APIs, so that both they and their users can upgrade without fuss to future Java releases. Strong encapsulation is controlled by the launcher option -–illegal-access, for JDK 9 until JDK 15 defaults to warning, and starting with JDK 16 defaults to deny. It is still possible (for now) to relax encapsulation of all packages with a single command-line option, in the future only opening specific packages with –add-opens will work.
JEP 397: Sealed Classes (Second Preview) (JDK-8246775)
Sealed classes and interfaces have been previewed again in JDK 16, initially added to the Java language in JDK 15. Sealed classes and interfaces restrict which other classes or interfaces may extend or implement them.
Removed Features and Options
Removal of java.awt.PeerFixer (JDK-8253965)
The non-public class
java.awt.PeerFixer has been removed in this release. This class was used to provide deserialization support of ScrollPane objects created prior JDK 1.1.1.
Removal of Experimental Features AOT and Graal JIT (JDK-8255616)
The experimental Java-based JIT compiler, Graal JEP317, has been removed. Attempting to use it produces a JVMCI error:
JVMCI compiler 'graal' not found.
Deprecated Tracing Flags Are Obsolete and Must Be Replaced With Unified Logging Equivalents (JDK-8256718)
When Unified Logging was added in Java 9, a number of tracing flags were deprecated and mapped to their unified logging equivalent. These flags are now obsolete and will no longer be converted automatically to enable unified logging. To continue getting the same logging output, you must explicitly replace the use of these flags with their unified logging equivalent.
Obsoleted OptionUnified Logging Replacement-XX:+TraceClassLoading-Xlog:class+load=info-XX:+TraceClassUnloading-Xlog:class+unload=info-XX:+TraceExceptions-Xlog:exceptions=info
Removed Root Certificates with 1024-bit Keys (JDK-8243559)
The following root certificates with weak 1024-bit RSA public keys have been removed from the
+ alias name "thawtepremiumserverca [jdk]"
Distinguished Name: EMAILADDRESSfirstname.lastname@example.org, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA+ alias name "verisignclass2g2ca [jdk]"
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US+ alias name "verisignclass3ca [jdk]"
Distinguished Name: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US+ alias name "verisignclass3g2ca [jdk]"
Distinguished Name: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US+ alias name "verisigntsaca [jdk]"
Distinguished Name: CN=Thawte Timestamping CA, OU=Thawte Certification, O=Thawte, L=Durbanville, ST=Western Cape, C=ZA
Removal of Legacy Elliptic Curves (JDK-8235710)
The SunEC provider no longer supports the following elliptic curves that are either obsolete or not implemented using modern formulas and techniques:
secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1 brainpoolP320r1, brainpoolP384r1, brainpoolP512r1
To continue using any of these curves, users must find third-party alternatives.
In this article, we found there is a lot of internal changes were made in Java 16. All these changes could improve the performance of your applications — don’t hesitate to check your app on the latest Java version.
Found this article useful? Follow me (Dmytro Timchenko) on Medium and check out my other articles below! Please 👏 this article to share it!
What’s new in Java 15
In this article, we will check what was added and removed in Java 15.
Integration Tests With Spring Boot, TestContainers, Liquibase, and JUnit 5
In this article, we will cover how to do integration tests in spring boot application with PostgreSQL DB, Liquibase…
Java Concurrency: Executors
In this article, we’ll cover Executors in java multithreaded programming and how to use them.
Top 5 New Java Features to Learn in 2021
Hello guys, Java is changing rapidly. Now there is a new release every six months and it's hard to keep up-to-speed…
67 New Features in JDK 16: https://www.azul.com/67-new-features-in-jdk-16/