OpenJDK has made available a list of major features that have been planned to appear in the next version of the JDK. It is the new version of the Java language. In all, OpenJDK introduced five new features, including a new implementation of the legacy socket API, improved ZGC garbage collection to return unused memory to the operating system, and the addition of text blocks. This is indeed a preview version that has been released. A release candidate (RC) has been scheduled for August 8th before the release of the stable version on September 17th.
Construction of JDK 13
This year’s second major release of JDK under the new OpenJDK release schedule, is finally complete. The new features have been made available to the community. This version of the JDK introduces five new features for the language. We have, in general, the reimplementation of the legacy socket API, dynamic archiving of classes, the addition of text blocks, switch expressions and improvement of ZGC (Z Garbage Collector) to return unallocated memory to the operating system. Let’s see in detail what it is about in this new version of the language.
ZGC (Z Garbage Collector) is improving
This is because ZGC does not currently disengage and does not return memory to the operating system, even if this memory has been unused for a long time. This behavior is not optimal for all types of applications and environments, especially those where memory footprint is a concern. For example, we have containers or environments in which an application can sit idle for a long time and share resources with other applications or compete for resources, etc. The functionality has been improved by the JDK 13 team to allow unallocated memory to be returned to the operating system.
Also, the JDK team clarified that other HotSpot garbage collectors, such as G1 and Shenandoah. Now it provide this capability, which some categories of users have found very useful. In this way, adding this capability to ZGC could also be welcomed by the same group of users.
The reimplementation of the legacy socket API
According to the explanations provided on the subject, the java.net.Socket and java.net.ServerSocket APIs, as well as their underlying implementations, date back to JDK 1.0. The implementation is a mixture of traditional Java and C code which is difficult to maintain and debug. Implementation uses the thread stack as an I / O buffer, an approach that required repeatedly increasing the size of the default thread stack. It uses a native data structure to support asynchronous shutdown, a source of subtle reliability and porting issues over the years. The implementation also has several concurrency issues that require an overhaul.
The new implementation will be easy to adapt to work with user-mode threads, also known as fibers. You can learn more from the JDK 13 release note provided for this purpose.
A second look at switch expressions
Switch expressions were first proposed in December 2017 by JEP 325. The current design of the switch statement in Java closely follows that of languages such as C and C ++ and supports the default processing of semantics. This traditional control flow is often useful for writing low-level code (like parsers for binary encodings), as a switch in higher-level contexts.
However, the JDK team feels that his error-prone nature is starting to outweigh his flexibility. So, based on this information, JDK 13 makes a change in functionality to generate a value from a switch expression. The “break with value” statement is removed in favor of a new “yield” statement. These changes will simplify daily coding and pave the way for the use of pattern filtering (JEP 305) in switch. This is a preview feature in JDK 13.
The dynamic archives of CDS
Archiving application classes using AppCDS in HotSpot provides additional boot time and memory advantages over the default CDS archive. However, a three-step procedure is currently required to use AppCDS for a Java application. It make one or more attempts to create a class list, then dump an archive using the created class list, and run with the archives. Additionally, the JDK team explained that this procedure only works for applications that only use built-in class loaders.
There is another experimental support for archiving classes in HotSpot, but it’s not easy to use. As such, dynamic archiving enabled by a command line option will simplify the use of AppCDS by eliminating testing (step 1 above). It will support both built-in class loaders and class loaders defined by the user in an efficient and uniform manner.
This would eliminate the step of explicitly creating archives. The use of CDS / AppCDS could then be completely transparent and automatic.
A preview of text blocks
In Java, embedding a snippet of HTML, XML, SQL, or JSON code in a “…” string literal usually requires extensive editing with escapes and concatenation before the code containing the snippet is compiled. The fragment is often difficult to read and difficult to maintain. This should no longer be the case with text blocks. A block of text is a multiline string literal that eliminates the need for most escape sequences. It automatically formats the string in a predictable way and gives the developer control over the format if they want. According to the team, this feature is still in the preview stage in JDK 13.
