Java Development Kit 19, which is due just this September, has just had a sixth feature proposed for it: a preview of record patterns, for data navigation and processing. Record patterns joins five previous features, ranging from a preview of a foreign function and memory API to support for the open source Linux/RISC-V instruction set architecture (ISA).
JDK 19, or simply Java 19, potentially could host a vast number of features, ranging from universal generics to value objects, according to plans underway for enhancing Java. JDK 19 would follow JDK 18, which arrived March 22. Standard Java is on a six-month release cadence.
OpenJDK's developers have published an official release schedule for JDK 19, which has it arriving September 20 as a production release, preceded by rampdown phases June 9 and July 21, and release candidates to be published August 11 and August 25.
Early access builds of JDK 19 can be accessed from jdk.java.net/19. Proposed JDK 19 features include:
- 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 Java runtime) 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 reincubated 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. This will allow developers to relax the historic null-hostility of
switchwhen desired, and is intended to increase the safety of
switchstatements and ensure 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 lanewide 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.