JDK 15: The new features in Java 15

Java Development Kit 15, Oracle’s implementation of the next version of Java SE (Standard Edition), becomes available as a production release today, September 15, 2020. Highlights of JDK 15 include text blocks, hidden classes, a foreign-memory access API, the Z Garbage Collector, and previews of sealed classes, pattern matching, and records.

JDK 15 is just a short-term release, only to be supported with Oracle Premier Support for six months until JDK 16 arrives next March. JDK 17, the next Long-Term Support release, to be supported by Oracle for eight years, is slated to arrive one year from now, as per Oracle’s six-month release cadence for Java SE versions.

Developers can look at JDK 15 now to get an idea of what will be in JDK 17, Georges Saab, president of Oracle’s Java Platform Group, said. The current LTS release is JDK 11, which arrived in September 2018. LTS releases arrive every three years. JDK 15 follows JDK 14, which was released on March 17, 2020. 

The new features and changes in OpenJDK 15:

• A second incubator of a foreign-memory access API, which would let Java programs safely and efficiently access foreign memory outside of the Java heap. The API should be able to operate on various kinds of foreign memory, such as native, persistent, and managed heap. Many Java programs access foreign memory, such as Ignite and MapDB. The API would help avoid the cost and unpredictability associated with garbage collection, share memory across processes, and serialize and deserialize memory content by mapping files onto memory. The Java API currently does not provide a satisfactory solution for accessing foreign memory. But with the new proposal, it should not be possible for the API to undermine the safety of the JVM. This capability is going through an earlier incubator phase in JDK 14, with refinements offered in JDK 15. 
• A preview of sealed classes. Along with interfaces, sealed classes restrict which other classes or interfaces may extend or implement them. Goals of this feature include allowing the author of a class or interface to control which code is responsible for implementing it, provide a more declarative way than access modifiers to restrict the use of a superclass, and support future directions in pattern matching by underpinning the exhaustive analysis of patterns.
• Removal of source code and build support for Solaris/SPARC, Solaris/x64, and Linux/SPARC ports, which were deprecated for removal in JDK 14 with the intent to remove them in a future release. Many projects and features in development such as Valhalla, Loom, and Panama require significant changes to CPU-architecture and operating system-specific code. Dropping support for Solaris and SPARC ports will enable contributors to the OpenJDK community to accelerate development of new features that will move the platform forward. Both Solaris and SPARC have been superseded in recent years by the Linux OS and Intel processors.
• Records, which are classes that act as transparent carriers for immutable data, would be included in a second preview version in JDK 15, after debuting as an early preview in JDK 14. Goals of the plan include devising an object-oriented construct that expresses a simple aggregation of values, helping programmers focus on modeling immutable data rather than extensible behavior, automatically implementing data-driven methods such as equals and assessors, and preserving longstanding Java principles such as nominal typing and migration compatibility. Records can be thought of as nominal tuples. 
• Cryptographic signatures based on the Edwards-Curve Digital Signature Algorithm (EdDSA). EdDSA is a modern elliptic curve scheme with advantages over existing signature schemes in the JDK. EdDSA will be implemented only in the SunEC provider. EdDSA is in demand because of its improved security and performance compared to other signature schemes; it is already supported in crypto libraries such as OpenSSL and BoringSSL.
• 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 easily and concisely. Languages such as Haskell and C# have embraced pattern matching for its brevity and safety.
• 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) graduates 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 class-data 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. ZGC addresses performance concerns in applications that involve massive amounts of data, such as machine learning, where users want to be sure that processing of data will not be subject to unpredictability or long pauses because of garbage collection. 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.
• Deprecation of the RMI Activation mechanism, for future removal. The RMI Activation mechanism is an obsolete part of RMI that has been optional since Java 8. RMI Activation imposes an ongoing maintenance burden. No other part of RMI will be deprecated.