Java 15 is here! Text Blocks & Shenandoah GC drop test status
Java 15’s GA release is finally here. 14 JEPs (Spoiler alert: Nashorn is out!) are part of the new JDK. Among other things, text blocks have moved beyond the experimental stage and the Shenandoah garbage collector is now a full member of the JDK. Let’s take a closer look at the JEPs of this release.
Migration to Git, which was examined as part of project Skara, will not take place as part of Java 15, since this move has already taken place. However, the corresponding JEPs (JEP 357: Migrate from Mercurial to Git & JEP 369: Migrate to GitHub) are officially part of Java 16.
JDK 15 news
The following JEPs are what Java 15 is made of, and are part of the JDK. The release date, September 15, was very apt for Java 15. A shame really, that we didn’t quite make it to 15 JEPs. However, for the 14 we got, you can read more about them below.
The goal of JEP 339 is to implement cryptographic signatures using the Edwards-Curve Digital Signature Algorithm (EdDSA). EdDSA is intended as an additional signature method in the JDK, not replacing anything. Its acknowledged improved security and performance over other schemes is a strong factor in making this part of the JDK, as is the fact it’s already supported by many other crypto libraries like OpenSSL and BoringSSL.
Coming from Java Language Architect Brian Goetz, JEP 360 will introduce sealed classes and interfaces to the JDK. He writes, “A sealed class or interface can be extended or implemented only by those classes and interfaces permitted to do so. […] A class is sealed by applying the sealed modifier to its declaration. Then, after any extends and implements clauses, the permits clause specifies the classes that are permitted to extend the sealed class.”
Additionally, sealed classes will work well with hidden classes and pattern matching. These are all important for project Valhalla, and will bring the JDK one step closer to achieving Valhalla’s goal of “enhancing abstraction, encapsulation, safety, expressiveness, and maintainability — without giving up performance.”
JEP 371 proposes to bring hidden classes to Java. They are classes that cannot be used directly by the bytecode of other classes. Hidden classes are intended for use by frameworks that generate classes at run time and use them indirectly, via reflection.
This is a very straightforward proposal to remove two modules that were deprecated for removal in Java 11 –
jdk.scripting.nashorn.shell. You can read what we had to say about JEP 372, or check it out in all its glory on the OpenJDK page.
The aim of JEP 373 is to refurbish the current
java.net.MulticastSocket API implementations with updated versions that will be easier to maintain and debug. In the current JDK, the implementations date back to the days of Java 1.0 and contain a mixture of legacy Java and C in their code, making them difficult to maintain and very easy to break. As a result, reimplementing these two API implementations would be a big step forward for the JDK. The current implementations will also remain in the JDK, but will no longer be the default options.
JEP 374‘s goal is to disable biased locking by default and deprecate all command-line options related to it. When it arrived in the JDK, biased locking brought a lot of complex code with it. Subsequently, as it gets older, complex code becomes complex legacy code, growing costly to maintain and standing in the way of progress due to the difficulties of making direct changes to the code or related systems. As such, much like with JEP 373, the time has come to work on some of the legacy features of Java. However, with JEP 374 the intention is not to remove biased locking, but disable and deprecate it. By doing this, Java applications whose performance would suffer without biased locking will retain the option to use it.
JEP 375 follows up on the groundwork done in Java 14 by JEP 305. As the name suggests, the feature will be returning for a second preview. Originally, it was planned for this second preview round to incorporate user feedback and include enhancements that would add deconstruction patterns to pattern matching, but it has since been decided to simply allow the feature a second preview round as-is, with further enhancements to the feature following later as JEPs. If you’d like to see this feature in action in Java 14, take a look at this deep dive into pattern matching.
Z Garbage Collector, introduced in JDK 11, has long been an experimental feature. However, it seems that with Java 15, the time has come for ZGC to become a production feature. Many changes and enhancements have been made to ZGC since its first appearance as part of the JDK—most recently, support for the Windows and macOS platforms. No new ZGC-specific bugs have been reported in the last months, suggesting it’s stable enough to no longer exist behind the
As for Text Blocks, they first came to Java in JDK 13 as a preview feature through JEP 355. Later on, they received a second preview through JEP 368 in JDK 14, with two additional escape sequences added following feedback from the community. Now, it looks like they are ready to become a standard feature, which is what JEP 378 is proposing.
The Shenandoah garbage collector was first integrated into the JDK back in Java 12 by JEP 189. Like other garbage collectors integrated into the JDK (such as Epsilon GC and ZGC), it was marked as experimental. Now, similar to the proposal put forward in JEP 377, Shenandoah is ready to become a production feature of future JDKs.
In Java 14, JEP 362 deprecated the Solaris and SPARC ports with the intent to remove them in the future. JEP 381 proposes the next logical step in that progression and aims to remove the source code specific to the Solaris operating system and SPARC architecture, as well as update the documentation and code comments for future releases.
Deprecating and removing the Solaris and SPARC ports seems to be motivated by the bigger projects in the Java ecosystem. Specifically, projects Valhalla, Loom, and Panama portend big changes to CPU-architecture and OS-specific code. Freeing the JDK of the Solaris and SPARC ports will allow development of these projects’ new features to go faster—and the community is eager to see these projects reach maturity.
JEP 383 brings the foreign-memory access API feature back for a second round as an incubating API. Originally, JEP 370 introduced this functionality to the JDK in Java 14. The API is coming back for a second round of incubation so it can incorporate some changes and refinements that have been suggested as a result of its first foray into the JDK.
The idea with this API is to add an API that allows Java programs to access so-called foreign memory, which refers to memory outside of the Java heap. Furthermore, the intention is to do this as safely and efficiently as possible.
JEP 384 aims to bring records back for a second round as a preview feature. JEP 359 brought records to JDK 14. Following user feedback and some refinements to support additional forms of local classes and interfaces in the Java language, JDK 15 will have a more complete feature for preview. Sealed types and pattern matching are good complements to records; we know that pattern matching is already proposed for JDK 15, but we will have to keep an eye out for sealed classes, which JEP 360 might bring to JDK 15 yet.
The final piece of JDK 15 is once again a tonic to slim down the JDK; the RMI activation mechanism is to be retired and marked as deprecated. The latter is responsible for ensuring that RMI-based services can export so-called stubs whose validity exceeds the life of a remote object or JVM containing it. The crux of the story is that “conventional” RMI stubs will be invalid immediately after the destruction of a remote object. The RMI Activation Service can help developers to resolve this situation using a complex error management logic. However, the mechanism is relatively rarely used, which is why JEP 385 is bringing it to an end.