Why Should You Care About JDK 18?

The latest update of the Java Development Kit (JDK 18) goes GA next week, and though it's not a Long-Term Support (LTS) release, it does implement nine JEPs (listed here). And while it's probably also true that your organization is going to want you to wait for the LTS coming in September 2023 (JDK 21), the JEPs implemented in this release are worth a look.

I joined a Zoom presser this week with two Java mavens, Simon Ritter and Steve Poole, to talk about the latest incarnation of the JDK and what it brings to developers.

Ritter is the Deputy CTO of Azul Systems, one of the leading open-source Java development tools and runtimes providers. He's a former Head of Java Technology Evangelism at Oracle, and he's a Java champion who's been working with the language and platform for more than two decades—all the way back to his days at Sun Microsystems.

Ritter said the very fact that this release isn't a headline grabber is a demonstration that Oracle's decision to provide JDK updates on a six-month release cadence is working.

"It's a time-based release model, rather than a feature-based release model," he said. "It doesn't mean that, since JDK 17, we've had six months of development and the people at Oracle and the rest of the contributors to the JDK haven't really been very busy. They've all been getting on with things. It's just that certain features haven't got to the point where they're ready for inclusion in the JDK in this six-month cycle."

Ritter pointed to Foreign Function & Memory API (JEP 419) as one of the more important JEPs implemented in this release, because it's one of those incubated components being included in Project Panama. Those following this years-long project will know that Panama is about simplifying the process of connecting Java programs to non-Java components. This particular feature, in its second incubation iteration, introduces an API through which Java programs call native libraries and process native data without the brittleness and danger of the Java Native Interface (JNI).

"This is a big thing because it's part of Project Panama," Ritter explained. "But also, because replacing the JNI is one of those features that will really help us as Java developers, because there are lots of libraries out there not written in Java—important things, like machine learning, for example."

Poole agreed that the JNI has been the Achilles Heel of Java ever since it was created. And he should know: He was there when it happened.

Currently a developer advocate at Sonatype, a leader in the DevSecOps and repository management space, Poole has been working on Java software development kits and JVMs for 25 years—since the dawn of Java, you could say. He has also been a developer advocate at Red Hat and IBM, as well as a member of the AdoptOpenJDK group, which is now the Eclipse Adoptium project, championing community involvement in OpenJDK.

"The JNI was deliberately created to be complicated," Poole said. "But you have to look at it in context. When Java came out, there was all this legacy code people wanted to connect to. But at the time, we did not want to encourage developers to use dated languages and propagate those environments. So that's the history, but since then, Sun, IBM, Oracle, and others have spent years experimenting with different ways of getting around this JNI thing. And we have to do it. If you look at, say, Python; it can call native code really, really easily. And that makes it very valuable. I would love to see this all finally hit the streets as a good solid practical API, because it's way overdue."

The only JEP implemented in this release that actually impacts the Java language is Pattern Matching for switch (JEP 420), which was first previewed in Java 17 (this is the second preview). Its purpose is to "enhance the Java programming language with pattern matching for switch expressions and statements, along with extensions to the language of patterns."

"We've seen in the last couple of iterations of the platform the introduction of much more pattern machine," Ritter said. "We're going have pattern matching for records and arrays, and I'm sure there will be other situations where we'll use pattern matching. This is one of those things that, again, is really helping developers, because it takes some of those rough edges off the language and eliminates boilerplate code."

JEP 420 is another example of an incubated components that's part of a larger project, in this case Project Amber, which aims to bring features to the language that can make writing Java code more readable and concise, and target specific use cases such as using generic enums or data classes.

"It's those little steps that are keeping things moving along quite nicely," Ritter said.

They both also pointed to JEP 421: Deprecate Finalization for Removal, which deprecates finalization for removal in a future release.Although the feature remains enabled by default for now, it can be disabled to facilitate early testing.

Finalization is a method used to perform cleanup operations on unmanaged resources held by the current object before the object is destroyed. It allows Java developers to perform "postmortem" cleanup on objects that the garbage collector has found to be unreachable. It has typically been used to reclaim native resources associated with an object.

"Let's be honest," Poole said, "two things were hacked into Java—and I do use the work 'hacked'—way back at the very beginning. One was serialization; the other was finalization. And again, finalization was added because, at the time, there were lots of resources that were in, say, C code, or database handles, and there needed to be a way to explicitly tell databases to close their resources or whatever. And we wanted to do it when Java objects were no longer needed when they were being destroyed. Also, it wasn't specified. The behavior was completely VM-specific, GC-specific, and what threading model you have—so it's a complete nightmare. Now it's finally being deprecated, and I really, really hope that by now there's nothing out there that relies on finalization, because that would be a very bad thing."

Both Poole and Ritter expect few people to use JDK 18 in production, because it's not an LTS release. The JDK 17 LTS release was much more significant, so there was something of a surge in the uptake of that release. Also, Oracle announced last year that it would begin providing an LTS every two years instead of every three, which means next LTS release (JDK 21) will ship in September 2023.

"For this release," Poole said, "mostly we'll see people kicking the tires."

Posted by John K. Waters on March 16, 2022