JDK 15: The new features in Java 15

The next version of standard Java will add text blocks, garbage collectors, and hidden classes and drop the Nashorn JavaScript engine

With Java 14 having reached general availability March 17, work has begun on the successor, Java 15, due in September 2020. Thus far five official changes have been slated for the release, the latest being hidden classes. Previous proposals include the addition of text blocks, the addition of the Z and Shenandoah garbage collectors, and the removal of the Nashorn JavaScript engine.

All five proposals have been targeted for Java Development Kit (JDK) 15, which is the basis for the next version of Java SE (Standard Edition). Text blocks and the removal of Nashorn were officially targeted for JDK 15 as of April 6, 2020, while the other three remain in the “proposed for targeting” stage.

The OpenJDK 15 proposal specifics:

  • Hidden classes, i.e. classes that cannot be used directly by the bytecode of other classes, are intended for use by frameworks that generate classes at runtime and that use them indirectly through reflection. A hidden class can be defined as a member of an access control nest and can be unloaded independently of other classes. The proposal would improve the efficiency of all languages on the JVM by enabling a standard API to define hidden classes that are not discoverable and have a limited lifecycle. Frameworks inside and outside the JDK would be able to dynamically generate classes that could instead define hidden classes. Many languages built on the JVM rely on dynamic class generation for flexibility and efficiency. Goals of this proposal include: allowing frameworks to define classes as non-discoverable implementation details of the framework, so they cannot be linked against by other classes nor discovered through reflection; support for extending an access control nest with non-discoverable classes; and support for aggressive unloading of non-discoverable classes, so frameworks have the flexibility to define as many as needed. Another goal is to deprecate the non-standard API, misc.Unsafe::defineAnonymousClass, with the intent to deprecate for removal in a future release. Also, the Java language is not to be changed as a result of this proposal.
  • The Z Garbage Collector (ZGC) would graduate from an experimental feature to a product under this proposal. Integrated into JDK 11, which arrived in September 2018, ZGC is a scalable, low-latency garbage collector. ZGC was introduced as an experimental capability because Java’s developers decided a feature of this size and complexity should be brought in carefully and gradually. Since then, a number of improvements have been added, ranging from concurrent class unloading, uncommitting of unused memory, and support for data-class sharing to improved NUMA awareness and multi-threaded heap pre-touching. Also, the maximum heap size has been increased from four terabytes to 16 terabytes. Platforms supported include Linux, Windows, and MacOS.
  • Text blocks, previewed in both JDK 14 and JDK 13, are intended to simplify the task of writing Java programs by making it easy to express strings that span several lines of source code, while avoiding escape sequences in common cases. A text block is a multi-line string literal that avoids the need for most escape sequences, automatically formats the string in a predictable manner, and offers the developer control over the format when desired. A goal of the text blocks proposal is enhancing the readability of strings in Java programs that denote code written in non-Java languages. Another goal is to support migration from string literals by stipulating that any new construct can express the same set of strings as a string literal, interpret the same escape sequences, and be manipulated in the same fashion as a string literal. The OpenJDK developers hope to add escape sequences to manage explicit white space and newline control.
  • The Shenandoah low-pause-time garbage collector would become a production feature and move out of the experimental stage. It had been integrated into JDK 12 a year ago.
  • Removal of Nashorn, which debuted in JDK 8 in March 2014, but has since been made obsolete by technologies such as GraalVM. The OpenJDK 15 proposal calls for removing Nashorn APIs and the jjs command line tool used to invoke Nashorn.

To continue reading this article register now