Overview
On 4th February, Java Development Kit (JDK) 16 was pushed to the candidate stage, where the availability of production release is set for 16th March. The latest features in JDK 16 range from a second preview to a pattern matching concurrent thread-stack processing for garbage collection. JDK 16 will be the benchmark of the standard Java version set to follow JDK 15, which was also released on 15th September. Check out our blog for knowing the features of JDK 15.
The JDK 16 stabilization repository has now opened with the release candidate to any P1 (high priority) bug fixes. Moreover, on 18th February, the draft schedule for the release of JDK 16 calls for a second release candidate.
The new Java 16 features include:
Warning For Value-Based Classes
The value-based class warning proposal defines the primitive wrapper classes as values-based. It deprecates their constructors for removal, thus triggering new alerts to deprecation. We get a warning concerning unsuitable attempts to synchronize instances on the Java platform for any value-based classes. A significant enhancement happens to the Java programming model in the form of primitive classes. Primitive groups announce that instances are free of identities and are also capable of inline or flattened representations. We copy the instances freely between the memory locations and encrypts with instance field values. The design and realization of primitive classes in Java are also now mature enough that a future version of the Java platform might predict such classes’ migration from primitive classes. Migration candidates are officially designating in API specifications as value-based classes.
Sealed Classes
Previously, JDK 15 showed sealed classes and interfaces that can be expanded or enforced by other classes and interfaces. The plan aims to include the supervision of the code responsible for the implementation by the creator of a class or interface. This provides a more declaratory way to limit the use of a superclass than access modifiers. And it promotes future pattern matching recommendations by creating the framework for pattern analysis.
Strongly Encapsulate JDK Internals By Default
Default JDK encapsulation is stable, with the exception of critical internal APIs like misc.Unsafe. Users can pick the simple and also strong encapsulation by default for JDK 9. The purpose of this proposal is to enhance the protection and maintenance of the JDK. This allows developers to switch from internal elements to standard APIs. So that both developers and end-users can quickly upgrade future versions of Java. This proposal is mainly at risk of failing to run existing Java code. Developers can use the jdeps tool to recognize code that relies on the inner JDK components and, when available, to turn to standard substitution. Developers can use an existing release to check the current code by using –illegal-access=warn. We do this to identify the internal elements accessed through reflection. —illegal-access=debug is to identify misleading code and use —illegal-access=deny for testing.
Foreign Linker API
Foreign Linker API, which allows pure Java access to native code with a static type. The API will take place in JDK 16 at the incubator level. The Foreign Linker API would greatly simplify the error-prone method of bonding to a Native Library along with the proposed foreign memory access API. This plan will substitute for a superior pure Java development model, java native interface (JNI). This offers C support and, over time, is reasonably versatile to support other platforms like C++. It also supports third-party features, such as 32-bit x86, in languages other than C. The result ought to be better than or equivalent to JNI.
ZGC: Concurrent Thread Stack Processing
Shift ZGC thread-stack processing (Z garbage collector) from a safe point to a concurrent phase. This plan’s goals include the elimination of thread-stacking from ZGC safepoints, the lazy, cooperative, concurrent, and also gradual stack processing, the removal from ZGC safepoints of all other per-thread root processing, and a framework for other HotSpot VM stacks. The following are in this plan.
ZGC is to make HotSpot GC breaks and scalability problems. Until now, GC operations with the heap size and the metaspace size have been transferred out of safe point operations in concurrent stages. These include labeling, relocation, processing of references, unloading classes, and most root processing. A root processing subset and time-limited labeling termination procedure are the only activities that we perform with GC safepoints. These roots include Java thread stacks and other thread roots since these roots scale with the number of threads. In order to go beyond the current situation, processing per thread, including stack scan, must be transferring to a competitor level.
Elastic Metaspace
An unused metadata-class HotSpot VM memory returns to the OS more quickly and elastically. This reduces the size of the metaspace and makes metaspace code easier to reduce maintenance costs. The use of high off-heap memory was problematic for metaspace. In order to fulfill the memory requests, the plan calls for the replacement of the existing memory allocator with the Buddy-based allotment scheme. Fragmentation will also be decreasing. Also, the OS will smoothly, on request, make the memory commitments for loaders that start with large arenas but do not utilize them immediately or could not fully use them.
Enable C++ 14 Language
To permit the use of C++ 14 functions in source code and JDK, C++ provide detailed instructions regarding the use of C++ 14 functionality for the HotSpot VM code. Limits the C++ Code features in the JDK to C++98/03 specifications by JDK 15. Modifies the source code with JDK 11 to support new C++ versions of construction. This includes the ability to construct compilers that support C++ 11/14 language capabilities in recent versions. There is no recommendation in this proposal to change the style or usage of C++ code that is being used except HotSpot. But it requires some modification, depending on the platform compiler, to take advantage of C++ language features.
Vector API
A vector API in an incubator process with the JDK equipped with a jdk.incubator.vector. This expresses vector calculations that compile vector hardware instructions. This ensures that supporting CPU architectures are superior to similar scalar calculations. Moreover, the Vector API offers a mechanism for writing complex vector algorithms in Java using the existing support for vectorization in HotSpot VM. But with the user model that enhances predictability and robust vectorization.
Windows/ AArch64 Port
Port JDK to the platform Windows/AArch64. Windows/AArch64 became a significant forum for demand by introducing the latest AArch64 server class and consumer hardware (ARM64). This proposal’s key focus is on integrating the port in the main JDK repository, even though the Porting itself is already complete.
Alpine Linux Port:
Port the JDK on x64 and AArch64 architects to alpine Linux and other Linux distributions that use musl as their main C library. Musl is a standard library that features Linux implementation as defined in the ISO C and Posix standards. Allowing Java to run out of the box in such settings will allow native operation for Tomcat, Jetty, Spring, and also for other common frameworks.
Records
They provide records for immutable data groups that function as transparent carriers. Nominal tuples may also be regarding as documents. Both in JDK 14 and JDK 15, they give records.
Unix-Domain Socket Channels
Adds a Unix domain socket to the nio.channels package’s socket channel and server socket channels API to support Unix-domain (AF UNIX) sockets.
An external memory access API that lets Java programs access external memories safely from Java. The Foreign-Memory Access API will be reconstructing into JDK 16, with refinements.
Pattern Matching For instanceof
Pattern matching for the instanceof operator, which was also previewed in JDK 14 and JDK 15. It was completed in JDK 16. Pattern matching permits basic logic to articulate more accurately and safely in a program, namely the conditional removal of components from objects.
Packaging Tool
Give the packaging tool for Java applications. Launches the package into JDK 14 as an incubating tool and stayed incubated in JDK 15. JPackage goes to production with JDK 16 and supports native package formats. This provides users with a natural installation experience and allows them to define start-time parameters during packaging.
Migration from Mercurial to Git
Migration from Mercurial to Git of OpenJDK source code repositories. This initiative’s benefits include the metadata size of the version control system and also the resource and hosting availability.
Migration to GitHub
JDK 16 source code repositories are on the common code-sharing website for migration to GitHub related to Mercurial-to-Git migration. On 5th September, the transition to Git, GitHub, and Skara was completed and opened for contribution for the Mercurial JDK and JDK sandbox.
Bottom Line
JDK 16 for Linux, Windows, and macOS can be found on jdk.java.net for construction. Like JDK 15, JDK 16, which is supported for six months, will be a short-term update. Moreover, JDK 16 will be releasing with the Java SE Platform Reference Implementation version 16.
Developers can look at this JDK 16 for an idea of the upcoming JDK 16 functionality. If you find this article useful, then please check out our other blogs! To know more about us visit our website.
