While the latest final version of Oracle’s Java Development Kit (JDK) was released less than a month ago, work to implement its successor, Java 15, scheduled to replace it in September 2020, are already launched.
Even if the official OpenJDK page does not talk about it yet, the OpenJDK proposal page indicates that JDK 15 is the target version of these proposed changes. The five proposals (if those under review are validated) should be official functionality for the Java Development Kit (JDK) 15, which is the basis for the next version of Java SE (standard edition).
Here are the specifics of these improvement proposals below:
- Text blocks for better legibility of character strings
- The addition of Z Garbage Collector (ZGC)
- The addition of the Garbage Collector Shenandoah
- Adding the Hidden Classes
A text block is a literal string of several lines which avoids most escape sequences, automatically formats the string in a predictable way and gives the developer control over the format when he wishes.
One of the objectives of the proposed text block is to improve the readability of strings in Java programs that indicate code written in languages other than Java. Another objective is to support migration from literal strings by stipulating that any new construction can express the same set of strings as a literal string, interpret the same escape sequences and be handled in the same way. than a literal string. The developers of OpenJDK hope to add escape sequences to manage explicit white space and control of new lines.
The withdrawal of Nashorn, which debuted in JDK 8 in March 2014, has since been made obsolete by technologies such as GraalVM. The OpenJDK 15 proposal provides for the removal of the Nashorn APIs and the jjs command line tool used to invoke Nashorn. According to the OpenJDK proposal page, the engine, APIs and tool had been deprecated in Java 11 with the express intention of removing them in a future release.
Its integration into JDK 15 would make it go from an experimental functionality to a final product within the framework of this proposal. Arrived by the JEP 333 and integrated into the JDK 11, which arrived in September 2018, the ZGC is a scalable and low-latency Collector, according to the proposal page. ZGC was introduced on an experimental basis at the time because the Java developers decided that a feature of this size and complexity should be introduced carefully and gradually.
The addition of the Shenandoah Garbage Collector with a short break time as part of this proposal would make this functionality a production element and leave the experimental stage. The GC Shenandoah was integrated into JDK 12 by the JEP 189. It was marked as experimental in order to correspond to the status of other new GCs, notably the GC Epsilon and ZGC. Today, Shenandoah is ready to give up its experimental status in the main JDKs.
The addition of this functionality was motivated, among other things, by the fact that many language implementations built on the JVM rely on the dynamic generation of classes for more flexibility and efficiency, according to the proposal page. “For example, in the Java language, javac does not translate a lambda expression into a dedicated class file at the time of compilation but, on the contrary, emits a bytecode which dynamically generates and instantiates a class to produce an object corresponding to the expression lambda when necessary ”, we read on the page.
Source : OpenJDK