Language feature: Sealed classes (JEP 409)

Sealed classes might be the most eagerly anticipated finalized feature in JDK 17, and they were previewed in JDK 16. In short, sealed classes restrict which other classes (or interfaces) may extend them. As JEP 409 describes, 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 و implements clauses, the permits clause specifies the classes that are permitted to extend the sealed class. If those classes are not expressly permitted to make changes, they can’t make changes.

Why should you care? According to Aurelio Garcia-Ribeyro, director of product management for Java SE, “Sealed classes allow me to create a set of options that I know is finite—and that simplifies code because then I can treat classes as if they were enums.”

Having sealed classes, he says, eliminates the concern that some other code can override your code or modify its behavior in ways you can’t anticipate. “It creates a guarantee that nobody can enhance a library in a way that will break my code in the future.”

Core library upgrade: Context-specific deserialization filters (JEP 415)

Context-specific deserialization filters build on a feature introduced in Java 9 (see JEP 290: Filter incoming serialization data). That old JEP offered both changeable per-stream deserialization filters and a static JVM-wide filter. The per-stream filters, unfortunately, did not scale well, and it’s difficult to update filters after code has been shipped. JEP 290’s filters also cannot impose filtering on deserialization operations performed by third-party libraries in an application. The JVM-wide filter was limited in that it was specified only once, at startup, and was sometimes too inclusive or too restrictive.

The new functionality in JEP 415 is presented as a JVM-wide filter factory. The filters are dynamic and context-specific. For backward compatibility, if a filter factory is not set, the built-in factory returns a static JVM-wide filter if one was configured.

The problem, says Garcia-Ribeyro, is that every time a developer created a pipeline, the developer had to define what the filter was, including an allowlist and a denylist. However, according to Garcia-Ribeyro, “If I’m using a third-party library, they are using their own streams. I could define a JVM-wide filter, but I had to know—ahead of time—everything that the library wanted to do. This required a lot of work.”

By contrast, JEP 415 provides a filter factory. “With a filter factory, deserialization filters are now immensely easier to use,” he says, “to the point that this is the one feature that we are already reworking and retrofitting, all the way to JDK 11 and JDK 8.”

There’s no time frame set for rolling JEP 415 back to the older version of Java, but Garcia-Ribeyro insists, “We’re furiously working on it.”

Core library update: New macOS rendering pipeline (JEP 382)

Do you use a Mac? I do—I don’t know what I’d do without my quad-core i7-based MacBook Pro. The new macOS rendering pipeline described by JEP 382 is pretty simple: It moves the JVM’s 2D graphics away from using the deprecated Apple OpenGL API to the newer Apple Metal API. Of course, if you’re using Java for back-end workloads, you likely won’t care about this.

Apple started phasing out OpenGL in macOS Mojave 10.14, advising, “The APIs in the OpenGL and OpenCL frameworks are deprecated and remain present for compatibility purposes. Transition to Metal if your app is using OpenGL or OpenCL.”

This change applies to both Intel- and ARM-based Macs. This is a hidden change. As the JEP 382 documentation says, “The changes are confined to macOS-specific code and even there only a minimal amount of code shared between Metal and OpenGL is updated. We did not introduce any new Java APIs, nor did we change any existing API.”

The JEP 382 documentation further notes, “Apple claims that the Metal framework, their replacement for OpenGL, has superior performance. For the Java 2D API, this is generally the case with some exceptions.”

For now, the Java 17 JVM will default to using OpenGL; it’ll use Metal only if OpenGL is not present or if the user throws a command-line switch. Garcia-Ribeyro asks, however, for Mac users to try the new code. “We want you to turn on this new rendering pipeline. It should be faster than, or at least the same as, the existing graphics performance on Macs.”

Preview: Pattern matching for switch (JEP 406)

I’ve probably heard more about pattern matching for switch (JEP 406) than any other JDK 17 feature—and Garcia-Ribeyro is excited about it too. “This feature makes Java better for everyone,” he says, “and a couple of releases down the line, it will become part of the Java standard.”

This JEP builds on the work in pattern matching for instanceof (JEP 394), which was finalized for JDK 16. The new feature offers two big benefits.

• It makes switch statements far more programmable and flexible by allowing patterns to appear in case labels. To quote the JEP documentation, “You can only switch on values of a few types — numeric types, enum types, and String — and you can only test for exact equality against constants. We might like to use patterns to test the same variable against a number of possibilities, taking a specific action on each, but since the existing switch does not support that, we end up with a chain of if...else tests.”
• It provides a more graceful (and developer-friendly) mechanism for handling null conditions. Again, to quote: “Traditionally, switch statements and expressions throw NullPointerException if the selector expression evaluates to null, so testing for null must be done outside of the switch…This was reasonable when switch supported only a few reference types. However, if switch allows a selector expression of any type, and case labels can have type patterns, then the standalone null test feels like an arbitrary distinction, and invites needless boilerplate and opportunity for error.”

I expect most developers will find that when they try pattern matching for switch, they’ll say, “Where have you been all my life?”