Java Development Kit 19, due this September, is now feature-complete, and is now in a second rampdown phase. Seven features target the release including structured concurrency, record patterns, a preview of a foreign function and memory API, and support for the open source Linux/RISC-V instruction set architecture (ISA).
With this latest milestone in the release process for standard Java, other planned capabilities such as universal generics and value objects will have to wait for a later version of the platform. JDK 19 follows the March 22 arrival of JDK 18. Standard Java is on a six-month release cadence.
JDK 19 is slated to be officially released for production use on September 20, preceded by release candidates to be published August 11 and August 25. An initial rampdown phase was reached last month. Early access builds of JDK 19 can be accessed from jdk.java.net/19. The JDK 19 features include:
- Structured concurrency, in an incubator phase, is intended to simplify multithreaded programming through a structured concurrency API. This concurrency treats multiple tasks running in different threads as a single unit of work, to streamline error handling and cancellation. Reliability and observability are improved.
- A preview of record patterns, to deconstruct record values. Record patterns and type patterns can be nested to enable a declarative, powerful, and composable form of data navigation and processing. Goals of the proposal include extending pattern matching to express more sophisticated, composable data queries while not changing the syntax or semantics of type patterns. This proposal builds on pattern matching for
instanceof, delivered in JDK 16 in March 2021. Future plans may call for record patterns to be extended with capabilities such as array patterns and
varargpatterns. Record patterns is part of Project Amber, an effort to explore and incubate smaller, productivity-oriented Java features.
- A preview of a foreign function and memory API, which would introduce an API by which Java programs can interoperate with code and data outside the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM) and safely accessing foreign memory (i.e., memory not managed by the JVM) the API enables Java programs to call native libraries and process native data without the danger and brittleness of the Java Native Interface (JNI). The foreign function and memory API combines two earlier incubating APIs: the foreign memory access API and the foreign linker API. The foreign function and memory API was previously incubated in JDK 17 and re-incubated in JDK 18. The proposal's goals include ease of use, performance, generality, and safety.
- A preview of virtual threads, which are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput, concurrent applications. Goals include enabling server applications written in the simple thread-per-request style to scale with near-optimal hardware utilization, enabling existing code that uses the
java.langThread API to adopt virtual threads with minimal change, and enable troubleshooting, debugging, and profiling of virtual threads with existing JDK tools. It is not a goal of this proposal to change the basic concurrency model in Java or offer a new data parallelism construct in either the Java language or Java libraries. Nor is it a goal to remove the traditional implementation of threads or to silently migrate existing applications to use virtual threads.
- A third preview of pattern matching for switch expressions and statements, extending pattern matching to
switch, to allow an expression to be tested against a number of patterns, each with a specific action, so complex data-oriented queries can be expressed concisely and safely. This capability previously was previewed in JDK 17 and JDK 18. The third preview would add refinements including the replacement of guarded patterns with
switchblocks. Also, the runtime semantics of a pattern switch when the value of the selector expression is null are more closely aligned with legacy
switchsemantics. The plan's goals include expanding the expressiveness and applicability of
switchexpressions and statements by allowing patterns to appear in case labels. Other goals include allowing developers to relax the historic null-hostility of
switchwhen desired, increasing the safety of
switchstatements and ensuring that existing
switchexpressions and statements continue to compile with no changes and execute with identical semantics.
- A fourth incubation of a vector API that would express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations. Developers using the API gain a way to write complex vector algorithms in Java, using the HotSpot auto-vectorizer but with a user model that makes vectorizations more predictable and robust. The vector API previously was incubated into JDK 16, JDK 17, and JDK 19.
Improvements to the API proposed for JDK 19 include enhancements to load and store vectors to and from
MemorySegments, as defined by the Foreign Function and Memory API preview. JDK 19 would also add two cross-lane vector operations, compress and expand, together with a complementary vector mask compress operation. The compress vector operation maps lanes of a source vector, selected by a mask, to a destination vector in lane order, while the expand operation does the inverse. The compress operation is useful in filtering query results.
In another addition to the vector API, bitwise integral lanewise operations would be expanded, including operations such counting the number of one bits, reversing the order of bits, and compressing and expanding bits. Goals of the API included being clear and concise, platform-agnostic, having reliable runtime and compilation performance on x64 and AArch64 architectures, and enabling "graceful" degradation, for situations in which a vector computation cannot be fully expressed at runtime as a sequence of vector operations.
- With the Linux/RISC-V port, Java would gain support for a hardware instruction set that is already supported by a wide range of language toolchains. RISC-V actually is a family of related ISAs. The Linux/RISC-V port would only support the RV64GV configuration of RISC-V, a general purpose 64-bit ISA that includes vector instructions. The developers of Java may consider other RISC-V configurations in the future.
The port would support the following HotSpot VM options: the template interpreter, C1 (client) JIT compiler, C2 (server) JIT compiler, and all current mainline garbage collectors including ZGC and Shenandoah. The actual porting is nearly complete; the focus of the JDK Enhancement Proposal (JEP) is integration of the port into the JDK mainline repository.
Like JDK 18, JDK 19 is due to be a short-term release, with only six months of top-level, Premier support.