With Java 14 having reached general availability March 17, work continues on the successor, Java 15, due September 15, 2020. The latest proposal eyed for the platform, as of June 1, 2020, is the deprecation of the RMI (Remote Method Invocation) Activation mechanism.
Java Development Kit (JDK) 15 provides 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.
Features that have reached the officially targeted stage include hidden classes, removal of the Nashorn JavaScript engine, reimplementing the legacy DatagramSocket API, disabling biased locking, pattern matching for instanceof, the ZGC and Shenandoah garbage collectors, text blocks, records, Edwards-Curve Digital Signature Algorithm (EDSA) cryptographic signatures, sealed classes, removal of Solaris and Sparc ports, and the foreign memory access API.
The OpenJDK 15 proposal specifics:
- 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.Socketandjava.net.MulticastSocketAPIs 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 ofjava.net.datagram.Socketandjava.net.MulticastSocketdate back to JDK 1.0 and a time when IPv6 was still under development. Thus the current implementation ofMulticastSockettries 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, 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.
- 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.
Early access builds of JDK 15 can be found at java.jdk.net. JDK 15 will be a short-term feature release, supported for six months according to Oracle’s six-month release cadence. The next long-term support (LTS) release, which will receive several years of support, will be JDK 17, which is due to arrive in September 2021. The current LTS release is JDK 11, which was released in September 2018.