With Java 14 having reached general availability March 17, work has begun on the successor, Java 15, due September 15, 2020. Thus far eight official changes have been slated for the release. Three proposals were added in early May, including replacing the legacy DatagramSocket API, a second preview of pattern matching for the instanceof operator, and disabling and deprecating biased locking.

All three new proposals were in the “propose for targeting” phase as of May 5. The five previous proposals have been officially targeted for Java Development Kit (JDK) 15, which is the basis for the next version of Java SE (Standard Edition). Prior to general availability in September, there will be rampdown phases in June and July, followed by two release candidates in August.

The OpenJDK 15 proposal specifics:

Reimplementing the legacy DatagramSocket API by replacing the underlying implementations of the java.net.datagram.Socket and java.net.MulticastSocket APIs with simpler and more modern implementations that (1) are easy to debug and maintain and (2) work with virtual threads currently being explored in Project Loom. The new plan is a follow-up to JDK Enhancement Proposal 353 that reimplemented the legacy Socket API. The current implementations of java.net.datagram.Socket and java.net.MulticastSocket date back to JDK 1.0 and a time when IPv6 was still under development. Thus the current implementation of MulticastSocket tries to reconcile IPv4 and IPv6 in ways that are difficult to maintain.
Disabling biased locking by default and deprecating all related command-line options. The goal is to determine the need for continued support of the costly-to-maintain legacy synchronization optimization of biased locking, which is used in the HotSpot virtual machine to reduce overhead of uncontended locking. Although some Java applications may see a regression in performance with biased locking disabled, the performance gains of biased locking are generally less evident than they used to be.
A second preview of pattern matching for instanceof, following a previous preview in JDK 14. Pattern matching allows common logic in a program, chiefly the conditional extraction of components from objects, to be expressed more concisely. Languages such as Haskell and C# have embraced pattern matching for its brevity and safety.
Hidden classes—meaning 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.