Java 19 improves concurrency with Project Loom virtual threads

Java 19 was released in the scheduled six-month cycle. The release brings a total of seven innovations in Java Enhancement Proposals (JEPs), two of which come from the Loom, Amber and Panama projects. They target concurrent programming, productivity, and connectivity to non-Java APIs.

A total of seven JEPs from three projects have made it into Java 19. However, the JEP 408 got lost: it must be called JEP 427.

Away from the projects, Java 19 brings with the JEP 422: Linux/RISC-V port an implementation for the RISC-V architecture. It is limited to the RV64GV configuration at launch, but is intended to be used for other configurations as well.

Project Loom aims at an improved and slimmer concurrency for Java programs. Loom means loom, i.e. the tool to join the threads into a large whole. Java 19 weaves in two JEPs from Project Loom as new preview features: Virtual Threads and Structured Concurrency.

That JEP 425 virtual threads denotes a new concept in Java for concurrent applications. The virtual threads supplement the previously used implementation via platform threads, which executes Java directly on operating system threads. Virtual threads use carrier threads as an additional layer. If a virtual thread stops on a blocking operation, the runtime can push another onto the carrier thread, allowing the platform thread to continue working.

The distribution and pooling of the individual threads is no longer the responsibility of the developers, but of the runtime environment. The implementation in Project Loom is explicitly not intended to replace the traditional implementation of the platform threads, but rather to complement them. Nor does it want to introduce a new concurrency model.

This is also part of Project Loom JEP 428 Structured Concurrency. The aim is to manage tasks from different threads in one unit in order to improve the maintainability and reliability of concurrent code. Like virtual threads in general, the concept is not new, and different languages ​​and frameworks offer different approaches to structured concurrency.

Java 19 leads the class StructuredTaskScope with which you create a task as a group of concurrent subtasks and manage it as a closed unit. The API knows, among other things, the default ShutdownOnFailure, which ensures that if an error occurs in one subtask, the others are stopped accordingly. Analogously there ShutdownOnSuccess stipulates that all subtasks finish their work when one has run successfully.

The two innovations in Project Amber relate to pattern matching. The project takes care of smaller language features that are intended to improve productivity. That JEP 427 pattern matching for switches is already marked Third Preview. It extends the pattern matching for switch statements and expressions that was first introduced in Java 17 under JEP 406 and continued in Java 18 as JEP 420. The latter were part of Java 14 as JEP 361, as was basic pattern matching as JEP 305.

JEP 405: Record Patterns is the first preview for deconstructing the values ​​in records. The latter construct for storing simple values ​​in the form of immutable data was available as a preview in Java 14 and 15 before becoming the standard in Java 16. The concept allows patterns to be nested, as in the following example from JEP:

record Point(int x, int y) {}
enum Color { RED, GREEN, BLUE }
record ColoredPoint(Point p, Color c) {}
record Rectangle(ColoredPoint upperLeft, 
                 ColoredPoint lowerRight) {}

static void printColorOfUpperLeftPoint(Rectangle r) {
    if (r instanceof Rectangle(ColoredPoint(Point p, 
                                            Color c),
                               ColoredPoint lr)) {

ProjectPanama aims at connecting Java programs to non-Java or JVM components such as C-based libraries and interfaces. JEP 424 Foreign Function & Memory API has preview status in JDK 19. The API, which goes by the acronym FFM, is intended to provide a uniform interface to code and data beyond the Java runtime. It combines the previous advances JEP 389 Foreign Linker API from Java 16 and those in Java 14 as JEP 370 launched Foreign-Memory Access API.

The aim is to replace the Java Native Interface (JNI) with a more elegant implementation. Among other things, the focus is on security aspects: Although the API allows the execution of external operations whose memory security is not guaranteed, it warns of the risk of memory errors.

That JEP 426 Vector API is still in the incubator, i.e. before the preview phase. However, the first surcharge for this was already available as JEP 338 in Java 16. The API is intended to bring an interface for vector calculation at CPU level. New features in the latest JEP include the connection to the FFM API to convert vectors into MemorySegment– Drop or load instances.

At the virtual press event for the release of JDK 19, Georges Saab, Senior Vice President for Development of the Java Platform Group and Chairman of the OpenJDK Board of Directors at Oracle, emphasized his company’s commitment to Java. Oracle is still the most important contributor to the JDK. As an example, he showed a chart of fixed issues in JDK 19.

According to its own statements, Oracle has fixed significantly more issues in Java 19 than the rest of the companies combined.

He also gave a few numbers about Java, according to which there are 10 million Java developers who have asked a total of 1.8 million questions on StackOverflow. According to Saab, there are a good 360 Java User Groups and 355 Java Champions worldwide. Recently, there are also one million certified Java developers.

Learn more about Java 19 leave the Oracle Blog remove. An overview of the new JEPs can be found in the release notes for JDK 19. the OpenJDK variant can be downloaded from the JDK site.


To home page

Leave a Comment