Java 16 is the most recent short-term incremental release, based on Java 15, and it was released on March 16, 2021. Records and sealed classes are just two of the unique features included in this release.
There are two new changes in jdk16.
ZGC (concurrent thread stack processing) JEP 376:
It increases the z garbage collector capacity by moving the thread stack processing from the safe point to the concurrent phase.
Even on a larger heap, it allows a sub milliseconds pause on GC safe points.
Elastic metaspace (JEP 387)
Another change is from the memory management for meta space. Earlier, when
the memory was not required, the unused space was returned to JVM, but the
space was not returned to OS by JVM. Because of this, class loader overhead and
fragmentation would be. Now in Java 16, this problem was resolved by JVM
returning data to OS, and now even the memory in small chunks is not wasted
and is allocated, which leads to reducing the overhead and fragmentation.
Features of java 16 include:
Warnings for Value-based classes proposal:
The warnings for value-based classes proposal classifies the primitive wrapper classes as value-based; hence, their constructors are deprecated for removal, leading to new deprecation warnings. Warnings are displayed when improper synchronization attempts are attempted on instances of any value-based classes on the Java platform. The Valhalla Project, which seeks to introduce primitive classes as a significant improvement to the Java programming model, is the driving force behind this endeavour. Primitive classes claim that instances are identity-free, capable of inline or flattened representations, and freely copyable between memory regions. Instances are also encoded using the values of their fields. Since Java's primitive class concept and implementation have reached a certain level of maturity, it is possible to anticipate that in a future release, some Java platform classes will be converted to primitive classes. Informally referred to as value-based classes in API specifications, migration candidates.
The ability of other classes and interfaces to extend or implement sealed classes and interfaces is constrained. They have first introduced in JDK 15 and then again in JDK 16. The goal of the plan is to provide the author of a class or interface control over the code that implements it, provide a declarative technique to limit the use of a superclass other than access modifiers, and pave the way for future advances in pattern matching by setting up pattern analysis.
JDK internals is, by default, strongly encapsulated, with the exception of several crucial internal APIs, such misc. Unsafe. Users have access to the relaxed, strong encapsulation option, which has been the standard since JDK 9. This proposal, which is a part of Project Jigsaw, aims to improve the security and maintainability of the JDK and encourage programmers to utilize standard APIs instead of internal ones so that programmers and end users may quickly update to new Java releases. The primary threat to this plan is that existing Java programmes won't execute. When standard substitutes are available, developers are urged to utilize the jdeps tool to find code that depends on JDK internal components. Developers can test existing code using an existing release, such as JDK 11, by testing with —illegal-access=deny, —illegal-access=debug, and —illegal-access=warn to discover internal items accessed via reflection.
Foreign API linker:
Using a pure-Java, statically typed linker API, access to native code is possible. This is the incubator stage of this API in JDK 16. The proposed foreign-memory access API should be used in conjunction with the foreign linker API to greatly reduce error-prone native library binding. This strategy aims to replace JNI (Java Native Interface) with a superior pure-Java development paradigm, support C, and eventually be adaptable enough to handle new platforms, like 32-bit x86, and foreign functions written in languages other than C, including C++. Performance ought to surpass or be on par with JNI.
Z Garbage collector:
Concurrently processing the thread-stack processing of the ZGC (Z Garbage Collector) from safe locations. With this strategy, thread-stack processing from ZGC safe points will be eliminated, stack processing will be made lazy, cooperative, concurrent, and incremental, all other per-thread root processing from ZGC safe points will be eliminated, and other HotSpot VM subsystems will be given a way to lazily process stacks. With ZGC, HotSpot GC pauses, and scaling problems should become a thing of the past. Up to this point, GC activities that scale with the size of the heap and the size of the meta space have been transferred from safe point operations to concurrent phases. These have included the majority of root processing, marking, relocation, reference processing, and class unloading. Only a portion of root processing and a time-limited marking termination operation are still carried out in GC safe points. These thread roots, which have the drawback of scaling with the number of threads, include Java thread stacks and other thread roots. Per-thread processing, including stack scanning, has to be moved to a concurrent phase to improve the problem. The time spent inside ZGC safe points on common machines should be less than one millisecond using this strategy, and the throughput penalty of the improved latency should be negligible.
Elastic meta space capability:
To save maintenance costs, an elastic meta space capability returns unused HotSpot VM class metadata (meta space) RAM to the OS more quickly and reduces the meta space footprint. There have been difficulties with Meta space’s significant off-heap memory usage. The strategy calls for swapping out the current memory allocator for a buddy-based allocation technique that offers an algorithm to partition memory to accommodate memory requests. This method, which has been applied in the Linux kernel, will enable memory to be allocated in more manageable chunks, lowering class-loader overhead. Fragmentation will be lessened as well. To minimize the footprint for loaders that begin with huge arenas but do not utilize them right away or may not use them to their full potential, the OS memory commitment to memory management arenas will also be carried out slowly, only when necessary. Meta space memory will be divided into equally sized granules that can be committed and uncommitted independently of one another to fully utilize the elasticity provided by buddy allocation.
Enabling C++ 14 features:
Enabling C++ 14 language features will make it possible for JDK C++ source code to leverage C++ 14 capabilities and will provide precise instructions on which features may be used in HotSpot VM code. The language capabilities available to C++ code in the JDK up until JDK 15 were restricted to the C++98/03 language standards. The source code was updated to support building with more recent iterations of the C++ standard with JDK 11. This includes having access to the latest compilers that support the C++ 11/14 language features while building. For C++ code used outside of HotSpot, no style or usage modifications are suggested by this proposal. However, depending on the platform compiler, some build-time adjustments may be necessary to utilize C++ language capabilities.
Incubator stage of vector API:
A vector API that is currently in the incubator stage and uses the JDK's incubator module, jdk.incubator.vector, to define vector computations that compile to the best possible vector hardware instructions on supported CPU architectures to outperform equivalent scalar computations in performance. The vector API offers a way to build sophisticated vector algorithms in Java while utilizing the HotSpot VM's pre-existing support for vectorization and a user model that makes vectorization more reliable and predictable. By supporting a wide range of CPU architectures, delivering consistent runtime compilation and performance on the x64 and AArch64 architectures, and offering a concise and simple API to describe a variety of vector operations, the proposal intends to be platform-agnostic. Another goal is "graceful degradation," in which a vector computation would deteriorate gracefully and continue to run if it could not be fully expressed at runtime as a series of hardware vector instructions, either because one CPU architecture does not support another or because some instructions are not supported by that architecture.
Porting JDK to windows/AArch64 and Alpine Linux:
Extending the JDK platform to Windows/AArch64. Windows/AArch64 has grown in importance due to demand as a new server-class, and consumer AArch64 (ARM64) hardware has been released. Although the actual porting is already mostly finished, the inclusion of the port into the mainline JDK repository is the major objective of this request.
Alpine Linux and other Linux distributions that use musl as their primary C library support the JDK's port to those architectures. Musl implements the standard library functionality made available by the ISO C and Posix standards in Linux. Alpine Linux is often used in cloud deployments, microservices, and container settings because of its small image size. A Linux Docker image is less than 6MB in size. Tomcat, Jetty, Spring, and other well-known frameworks will operate in these systems natively if Java is allowed to run out of the box in such circumstances. A user can construct an even smaller image designed to execute a particular application by using jlink to shrink the Java runtime.
Offering record types that serve as transparent containers for immutable data Nominal tuples can be regarded as records. JDK 14 and JDK 15 provided previews of one of the most eagerly awaited innovations in the release: lowering the ceremonial of Java by eliminating boilerplate code. The plan aims to create an object-oriented construct that expresses a straightforward aggregation of values, assists developers in modelling immutable data as opposed to extensible behaviour, automatically implements data-driven methods like equals and accessors and maintains enduring Java principles like nominal typing and migration compatibility.
Unix-domain socket channels have been added, enabling support for AF UNIX sockets in the socket channel and server socket channel APIs of the nio. channels package. The plan also extends the inherited channel system to accommodate server socket channels and sockets in the Unix domain. On the same host, interprocess communication takes place across Unix-domain sockets. In most ways, they are comparable to TCP/IP sockets, with the exception that filesystem path names are used to address them rather than IP addresses and port numbers. The new functionality aims to support all Unix-domain socket channel features that are shared by Windows and the main Unix platforms. In terms of reading/write behaviour, connection formation, accepting incoming connections from servers, and multiplexing with other non-blocking selectable channels in a selector, Unix-domain socket channels will operate similarly to current TCP/IP channels. TCP/IP loopback connections are less dependable and less effective for local, inter-process communication than Unix-domain sockets.
Foreign memory access API:
Java programs can securely access foreign memory outside of the Java heap. JDK 16 would re-incubate the foreign-memory access API with improved functionality after it had previously been incubated in JDK 14 and JDK 15. Now that their different roles in the system are clearly defined, the Memory Segment and Memory Addresses interfaces. This proposal aims to provide a single API that can be used to access native, persistent, and managed heap memory, among other types of foreign memory. The security of the JVM shouldn't be jeopardized by the API. The idea is motivated by the fact that many Java programmes access external memory, including Ignite, Memcached, and MapDB. But there isn't a good way to access foreign memory using the Java API.
Pattern matching for the instanceof operator, which was previewed in JDK 14 and JDK 15. JDK 16 would contain the final version. In particular, the conditional extraction of components from objects can be represented more concisely and safely in a programme thanks to pattern matching.
Jpackage, which was first introduced as an incubator tool in JDK 14, remains an incubator in JDK 15. In order to provide users with a natural installation experience and to enable the specification of launch-time settings at the time of packaging, JDK 16 sees the introduction of jpackage, which now supports native package formats. On Windows, these formats include MSI and exe. On macOS, pkg and dmg, and on Linux, deb and rpm. The utility can be used programmatically or straight from the command line. Instead of being added to the classpath or module path, many Java programmes need to be installed on native systems in a first-class manner. This is a problem that the new packaging tool attempts to solve. For the native platform, an installable package is required.
Migration to GitHub:
Migration from Mercurial to Git to GitHub, with JDK 16 source code repositories moving to the well-known code-sharing platform. This plan would include JDK feature releases and JDK update releases for Java 11 and later. The Mercurial JDK and JDK-sandbox moved to Git, GitHub, and Skara on September 5 and are now accepting contributions.
Java version 16 API specification:
- java. base – foundational APIs of Java SE
- java. compiler – Java compiler APIs, Language Model, Annotation Processing.
- java. data transfer – transferring data between applications
- Java. instrument – instrument running programs on JVM
- java. desktop – AWT and Swing user interface toolkits
- Java. management – Management Extensions (JMX) API
- java. logging – logging API
- java. management. rmi – RMI convertor Remote API
- java. net. HTTP – HTTP and Web Socket APIs
- java. naming – Java naming and Directory Interface (JNDI)
- java. RMI – Remote Method Invocation API
- java. prefs – Preferences API
- java. se – Platform API
- java. scripting – Scripting API
- java. security. sasl – Simple Authentication and Security Layer (SASL)
- java. security. jgss – Generic Security Services API (GSS – API)
- java. SQL – JDBC API
- java. smartcardio – Smart Card I/O API
- java. SQL. rowset – JDBC RowSet API
- java. XML – JAXP, StAX, SAX, W3 Document Object Model DOM API.
- java. transaction. xa – supporting distributed transactions in JDBC
- java. XML. crypto – XML Cryptographic API
- jdk. accessibility – JDK utility classes (Assistive Technology)
- jdk. attach – attach API
- jdk. compiler – system java compiler javac
- jdk. charsets – access to Charsets that are not in Java. base.
- jdk. crypto.ec – SunEC security provider.
- jdk. dynalink – dynamic linking of high-level operations
- jdk. crypto. cryptoki – SunPKCS11 security provider.
- jdk. httpserver – HTTP server API (jdk specific)
- jdk. editpad – edit pad service (jdk.jshell)
- jdk. incubator. vector – SIMD instructions, and NEON instructions on AArch64, AVX instructions on x64.
- jdk. hotspot. agent – HotSpot Serviceability Agent
- jdk. incubator. foreign – access for calling foreign memory and foreign functions
- jdk. javadoc – system documentation tool (Javadoc)
- jdk. jartool – manipulating JAR files ( JAR and Jarsinger tools)
- jdk. jconsole – managing and monitoring a running application (JMX graphical tool.
- jdk. jcmd – diagnostic, troubleshooting jps. jstat, jcmd
- jdk. JDI – Java debugs interface
- jdk. jdeps – dependencies in java programs and libraries, jdeprscan, jdeps, javap.
- jdk. JDWP. agent – Java Debug Wire Protocol (JDWP ) AGENT.
- jdk. jfr – JDK flight recorder.
- jdk. package – packaging tool, jpackage.
- jdk. jlink – run time images, JMOD files, image tool.
- jdk. jstatd – jstat tool to monitor JVM statistics remotely.
- jdk. jshell – jshell tool, JDK Specific API, Modelling, executing snippets.
- jdk. localedata – locale data for locales other than US locale.
- jdk. management. agent – JMX management agent
- jdk. management – JDK specific management interfaces
- jdk. management. jfr – JDK Flight Recorder, Management Interface
- jdk .naming. RMI – RMI Java Naming provider.
- jdk. naming. DNS – DNS Java Naming provider.
- jdk. nio. mapmode – specific file mapping modes.
- jdk .net – specific Networking API.
- jdk. security. auth – interfaces and authentication modules.
- jdk. sctp – JDK-specific API for SCTP.
- jdk. Security. jgss – GSS-API extensions, SASL GSSAPI mechanism
- jdk. zipfs – Zip file system provider.
- jdk. XML. dom – DOM API, which is not a part of Java SE