Java 15: Sealed classes bring Valhalla one step closer
Next stop, Java 15! Yes, now that Java 14 is out in the wild, we’ve got our eyes set on the next destination, JDK 15. We will be keeping track of all the Java 15 news throughout its development. Three new JEPs lay more groundwork for big projects like Valhalla, Loom, and Panama. Plus, three more features have been confirmed for JDK 15. Let’s take a closer look.
In the wake of Java 14’s release and considering the current state of the world, September seems like a long way off. Stay up to date with our informative Java 15 news updates, right here.
JDK 15 news
It’s been a busy week for Java: JEPs 373, 374 and 375 have been confirmed to target JDK 15. Additionally, three new JDK Enhancement Proposals were proposed to target Java 15.
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.”
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.
Stay tuned for more Java 15 news. In the meantime, we’ve collected more information about the upcoming JDK below.
These JEPs are also proposed to target Java 15; we’re waiting to see if they will be confirmed for the upcoming version. We will update this article once we know.
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.
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.
Java 15 – What we know
The first step on the road to Java 15 was taken in December when the Expert Group was formed. The group is comprised of the following members: Simon Ritter (Azul Systems), Manoj Palat (Eclipse Foundation), Tim Ellison (IBM), Andrew Haley (Red Hat), Christoph Langer (SAP SE), Iris Clark (Oracle) and Brian Goetz (Oracle).
These are all of the JEPs currently confirmed to target JDK 15:
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.
This is the proposed release schedule from Mark Reinhold. The original schedule and discussion can be found on the mailing list.
|2019/12||Expert Group formation|
|2020/06/11||Rampdown Phase One|
|2020/07/16||Rampdown Phase Two|
|2020/08/06||Initial Release Candidate|
|2020/08/20||Final Release Candidate|