Java 19 improves concurrency with Project Loom virtual threads

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

Virtual threads on the loom

Project Loom aims to improve and streamline 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.

The JEP 425 Virtual Threads designates 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.

Structured assignment of tasks

Also part of Project Loom is the 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.

Project Amber and Pattern Matching

The two innovations in Project Amber relate to pattern matching. The project takes care of smaller language features that are intended to improve productivity. The JEP 427 Pattern Matching for switch 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)) {
        System.out.println(c);
    }
}

Oh how nice is Panama

Project Panama aims to connect 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 the Foreign Memory Access API started in Java 14 as JEP 370.

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.

The 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.

Oracle’s commitment to Java

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.

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.

More information about Java 19 can be found on the Oracle blog. An overview of the new JEPs can be found in the release notes for JDK 19. The OpenJDK version can be downloaded from the JDK site.