Article originally posted on InfoQ. Visit InfoQ

JDK 19, the second non-LTS release since JDK 17, has reached its initial release candidate phase as declared by Mark Reinhold, chief architect, Java Platform Group at Oracle. The main-line source repository, forked to the JDK stabilization repository in early June 2022 (Rampdown Phase One), defines the feature set for JDK 19. Critical bugs, such as regressions or serious functionality issues, may be addressed, but must be approved via the Fix-Request process. As per the release schedule, JDK 19 will be formally released on September 20, 2022.

The final set of seven (7) new features, in the form of JEPs, can be separated into three categories: Core Java Library, Java Specification and Hotspot Compiler

Four (4) of these new features are categorized under the Core Java Library:

Two (2) of these new features are categorized under the Java Specification:

And finally, one (1) lone feature is categorized under the Hotspot Compiler:

We examine these new features and include where they fall under the auspices of the four major Java projects – Amber, Loom, Panama and Valhalla – designed to incubate a series of components for eventual inclusion in the JDK through a curated merge.

Project Amber

JEP 405, Record Patterns (Preview), proposes to enhance the language with record patterns to deconstruct record values. Record patterns may be used in conjunction with type patterns to “enable a powerful, declarative, and composable form of data navigation and processing.” Type patterns were recently extended for use in switch case labels via JEP 406, Pattern Matching for switch (Preview) (delivered in JDK 17), and JEP 420, Pattern Matching for switch (Second Preview) (delivered in JDK 18). More details on JEP 405 may be found in this InfoQ news story.

JEP 427, Pattern Matching for switch (Third Preview), incorporates enhancements in response to feedback from the previous two rounds of preview: JEP 406, Pattern Matching for switch (Preview) (delivered in JDK 17), and JEP 420, Pattern Matching for switch (Second Preview) (delivered in JDK 18). Changes from JEP 420 include: guarded patterns are replaced with when clauses in switch blocks; and runtime semantics of a pattern switch are more closely aligned with legacy switch semantics when the value of the selector expression is null.

Project Loom

JEP 425, Virtual Threads (Preview), introduces virtual threads, lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications, to the Java platform. More details on JEP 425 may be found in this InfoQ news story and this JEP Café screen cast by José Paumard, Java developer advocate, Java Platform Group at Oracle.

JEP 428, Structured Concurrency (Incubator), proposes to simplify multithreaded programming by introducing a library to treat multiple tasks running in different threads as a single unit of work. This can streamline error handling and cancellation, improve reliability, and enhance observability. Further details on JEP 428 may be found in this InfoQ news story.

Project Panama

JEP 424, Foreign Function & Memory API (Preview), introduces an API for Java applications to interoperate with code and data outside of the Java runtime by efficiently invoking foreign functions and by safely accessing foreign memory that is not managed by the JVM. This JEP evolves: JEP 419, Foreign Function & Memory API (Second Incubator), delivered in JDK 18; and JEP 412, Foreign Function & Memory API (Incubator), delivered in JDK 17; to incorporate improvements based on Java community feedback.

JEP 426, Vector API (Fourth Incubator), incorporates enhancements in response to feedback from the previous three rounds of incubation: JEP 417, Vector API (Third Incubator) (delivered in JDK 18), JEP 414, Vector API (Second Incubator) (delivered in JDK 17), and JEP 338, Vector API (Incubator), delivered as an incubator module in JDK 16. JEP 426 proposes to enhance the Vector API to load and store vectors to and from a MemorySegment as defined by JEP 424, Foreign Function & Memory API (Preview).

Hotspot Compiler

JEP 422, Linux/RISC-V Port, proposes to port the JDK to Linux/RISC-V, a free and open-source RISC instruction set architecture. The template interpreter, C1 and C2 JIT compilers, and all current mainline GCs, including ZGC and Shenandoah, will be supported. The main focus of this JEP is to integrate the port into the JDK main-line repository.

JDK 20

Scheduled for a GA release in March 2023, there are no targeted JEPs for JDK 20 at this time. However, based on recently submitted JEP drafts and JEP candidates, we can surmise which JEPs have the potential to be included in JDK 20.

JEP 429, Extent-Local Variables (Incubator), under the auspices of Project Loom, proposes to enable sharing of immutable data within and across threads. This is preferred to thread-local variables, especially when using large numbers of virtual threads. More details on JEP 429 may be found in this InfoQ news story.

JEP Draft 8277163, Value Objects (Preview), a feature JEP under the auspices of Project Valhalla, proposes the creation of value objects – identity-free value classes that specify the behavior of their instances. This draft is related to JEP 401, Primitive Classes (Preview), which is still in Candidate status.

JEP 401, Primitive Classes (Preview), also under the auspices of Project Valhalla, introduces developer-declared primitive classes – special kinds of value classes as defined in the aforementioned Value Objects (Preview) JEP Draft – that define new primitive types.

JEP Draft 8273943, String Templates (Preview), a feature JEP proposes to enhance the Java programming language with string templates, which are similar to string literals but which contain embedded expressions that are incorporated into the string template at run time.

JEP Draft 8280836, Sequenced Collections, proposes to introduce “a new family of interfaces that represent the concept of a collection whose elements are arranged in a well-defined sequence or ordering, as a structural property of the collection.” This is motivated by the lack of a well-defined ordering and uniform set of operations within the Collections Framework.

JEP Draft 8284289, Improved Way of Obtaining Call Traces Asynchronously for Profiling, a feature JEP type, proposes to define an efficient API for obtaining asynchronous call traces for profiling from a signal handler with information on Java and native frames.

JEP Draft 8283227, JDK Source Structure, an informational JEP, describes the overall layout and structure of the JDK source code and related files in the JDK repository. This JEP proposes to help developers adapt to the source code structure as described in JEP 201, Modular Source Code, delivered in JDK 9.

JEP Draft 8280389, ClassFile API, proposes to provide an API for parsing, generating, and transforming Java class files. This JEP will initially serve as an internal replacement for ASM, the Java bytecode manipulation and analysis framework, in the JDK with plans to have it opened as a public API. Brian Goetz, Java language architect at Oracle, characterized ASM as “an old codebase with plenty of legacy baggage” and provided background information on how this draft will evolve and ultimately replace ASM.

JEP Draft 8278252, JDK Packaging and Installation Guidelines, an informational JEP, proposed to provide guidelines for creating JDK installers on macOS, Linux and Windows to reduce the risks of collisions among JDK installations by different JDK providers. The intent is to promote a better experience when installing update releases of the JDK by formalizing installation directory names, package names, and other elements of installers that may lead to conflicts.

We anticipate that Oracle will start targeting some of these and other JEPs for JDK 20 very soon.