OpenJDK Provider Azul Systems Weighs in on Java 19
After Oracle delivered Java 19 recently, Simon Ritter, Deputy CTO of Azul Systems, met with The New Stack to share some technical insight on the features of the release — also known as Java Development Kit (JDK) 19 — and how it differs from the older versions. Azul is a key contributor to the OpenJDK project and the provider of the Zulu OpenJDK distribution.
Simon Ritter
What sets Java 19 apart from its predecessors?
JDK 19 continues the steady pace of development for the Java platform, the tenth release since the switch to a time-based, six-month release cadence. This release, like most, is classified as a feature release rather than long-term support (LTS) release, meaning it is unlikely that users will deploy it in production unless they use a systematic CI/CD strategy and can change JDK without issue.
What are some of the key new features?
All the JDK Enhancement Proposals (JEPs) included with JDK 19 (excluding JEP 422 Linux/RISC-V port) are either preview features or incubator modules. This indicates that they are still subject to change before becoming final.
The two big JEPs in JDK 19 are part of the larger Project Loom, intended to enable better and more scalable concurrency in Java. The first part of this is JEP 425, Virtual Threads. Rather than mapping each JVM [Java Virtual Machine] thread to an operating system (OS) thread, multiple JVM threads can share an OS thread. The JVM is responsible for scheduling and context-switching the Java threads. This is useful in web-based applications that handle very high numbers of connections that spend long periods idle (for example, when a user is making a decision). Rather than holding an OS thread (which are more limited in number), many connections can share a single OS thread and only use it when required.
The second part is JEP 428, Structured Concurrency. This aims to simplify Java concurrent programs by treating multiple tasks running in different threads (forked from the same parent thread) as a single unit of work. JEP 428 provides a mechanism to split a task into concurrent subtasks, which all return to the same place: the task’s code block. An obvious question related to this is how does this differ from the existing ForkJoinPool functionality? ForkJoinPool is designed to handle compute-intensive tasks, whereas the structured concurrency API is for I/O-intensive tasks.
What else strikes your fancy regarding Java 19?
At the Java language level, there is an update to Pattern Matching for Switch. The most significant change is to use when rather than for guarded patterns. In addition, JEP 405 introduces more Pattern Matching this time for records. By matching against a record type declaration, the compiler can handle deconstruction, and the record’s elements can be accessed directly.
The Foreign Function and Memory (FFAM) API has been moved to a preview feature from an incubator module. This is part of Project Panama, which replaces the Java Native Interface (and also provides a public API for some of the functionality in sun.misc.Unsafe). The Vector API (not to be confused with the Vector collections class) has been updated and provides closer integration with the FFAM API. This API aims to enable programmer-level control of using SIMD vector operations at the CPU level.
In summary, JDK 19 is another release with lots to appeal to developers and keeps the Java platform moving forward.
