JDK 19 — The Dawn of a Concurrency RevolutionVirtual Threads — The Debut of Lightweight Threads (JEP 425)Structured Concurrency — Organizing Concurrent Tasks (JEP 428)Record Patterns — The Beginning of Destructuring (JEP 405)Pattern Matching for switch — Third Preview (JEP 427)Foreign Function & Memory API — Preview (JEP 424)I/O-Bound Throughput InnovationSummary
javajdk19virtual-threadsstructured-concurrency

JDK 19 Key Features — The Debut of Virtual Threads and Structured Concurrency

· 9 min read

JDK 19 — The Dawn of a Concurrency Revolution

Java 19, released in September 2022, is a non-LTS release. While the feature count is modest, it’s a historic version where features that will transform Java’s concurrency programming paradigm appeared for the first time. Virtual Threads and Structured Concurrency were introduced as preview/incubator features, and Record Patterns and switch pattern matching continued to evolve.

JEPFeatureStatus
JEP 425Virtual ThreadsPreview
JEP 428Structured ConcurrencyIncubator
JEP 405Record PatternsPreview
JEP 427Pattern Matching for switch (Third Preview)Preview
JEP 424Foreign Function & Memory APIPreview
JEP 426Vector API (Fourth Incubator)Incubator

Virtual Threads — The Debut of Lightweight Threads (JEP 425)

Virtual Threads are lightweight threads managed by the JVM. Unlike traditional Platform Threads that map 1:1 to OS threads, millions of Virtual Threads can run on a small number of OS threads (Carrier Threads).

Using a restaurant analogy: Platform Threads are like “one dedicated waiter per customer,” while Virtual Threads are like “a few waiters who take orders -> wait for the kitchen -> serve other customers.” By serving others while waiting for the kitchen (I/O), overall throughput increases.

import java.time.Duration;
import java.time.Instant;
import java.util.concurrent.Executors;
import java.util.stream.IntStream;

public class VirtualThreadDemo {
    public static void main(String[] args) throws Exception {
        // Platform Thread pool: maximum 200 concurrent executions
        Instant start1 = Instant.now();
        try (var executor = Executors.newFixedThreadPool(200)) {
            IntStream.range(0, 10_000).forEach(i ->
                executor.submit(() -> {
                    Thread.sleep(Duration.ofMillis(100));
                    return i;
                })
            );
        }
        Duration platformTime = Duration.between(start1, Instant.now());

        // Virtual Threads: 10,000 concurrent executions
        Instant start2 = Instant.now();
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            IntStream.range(0, 10_000).forEach(i ->
                executor.submit(() -> {
                    Thread.sleep(Duration.ofMillis(100));
                    return i;
                })
            );
        }
        Duration virtualTime = Duration.between(start2, Instant.now());

        System.out.println("Platform Thread (200 pool): " + platformTime.toMillis() + "ms");
        System.out.println("Virtual Thread (10,000): " + virtualTime.toMillis() + "ms");
        // Platform Thread (200 pool): ~5000ms (50 batches of 200)
        // Virtual Thread (10,000): ~200ms (nearly simultaneous)
    }
}

Here’s a summary of Virtual Thread key characteristics:

ItemPlatform ThreadVirtual Thread
Creation costHigh (~1MB stack)Low (~1KB)
Concurrent countThousandsMillions
SchedulingOS kernelJVM ForkJoinPool
During I/O blockingOS thread occupiedCarrier Thread yielded
PoolingRequiredUnnecessary (create per task)
Suitable forCPU-intensiveI/O-bound

Virtual Threads don’t make code “run faster.” The purpose is to yield the Carrier Thread to other work during I/O wait time, dramatically increasing overall throughput.

Structured Concurrency — Organizing Concurrent Tasks (JEP 428)

Traditional ExecutorService runs tasks independently without parent-child relationships. If one fails, the rest keep running; cancellation propagation is manual; and during debugging, it’s hard to see relationships in thread dumps.

Structured Concurrency groups concurrent tasks into a single logical unit for lifecycle management. If one child task fails, the rest are automatically cancelled, and when the parent scope ends, all children are completed.

import java.util.concurrent.ExecutionException;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;

public class StructuredConcurrencyDemo {
    // User info retrieval simulation
    record UserProfile(String name, String email) {}
    record OrderHistory(int orderCount, int totalAmount) {}
    record UserDashboard(UserProfile profile, OrderHistory orders) {}

    // Fetch user profile (takes 500ms)
    static UserProfile fetchProfile(int userId) throws InterruptedException {
        Thread.sleep(500);
        return new UserProfile("User" + userId, "user" + userId + "@example.com");
    }

    // Fetch order history (takes 300ms)
    static OrderHistory fetchOrders(int userId) throws InterruptedException {
        Thread.sleep(300);
        return new OrderHistory(15, 1_250_000);
    }

    public static void main(String[] args) throws Exception {
        int userId = 42;

        // Traditional approach: parallel fetch with ExecutorService
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            Future<UserProfile> profileFuture = executor.submit(
                () -> fetchProfile(userId)
            );
            Future<OrderHistory> ordersFuture = executor.submit(
                () -> fetchOrders(userId)
            );

            // Combine both results — if one fails, the other keeps running
            UserProfile profile = profileFuture.get();
            OrderHistory orders = ordersFuture.get();

            UserDashboard dashboard = new UserDashboard(profile, orders);
            System.out.println("Name: " + dashboard.profile().name());
            System.out.println("Email: " + dashboard.profile().email());
            System.out.println("Order count: " + dashboard.orders().orderCount());
            System.out.println("Total amount: " + dashboard.orders().totalAmount());
            // Name: User42
            // Email: user42@example.com
            // Order count: 15
            // Total amount: 1250000
        }

        // Structured Concurrency uses StructuredTaskScope (incubator)
        // If one fails, the rest are auto-cancelled; all tasks complete when scope ends
        // In JDK 19, requires jdk.incubator.concurrent module
        System.out.println("\nStructured Concurrency -> evolves to preview in JDK 21");
    }
}

Key benefits of Structured Concurrency:

  • Failure propagation: Other child tasks auto-cancelled when one fails
  • Cancellation propagation: All children cancelled when parent is cancelled
  • Observability: Parent-child relationships visible in thread dumps
  • Resource leak prevention: All child tasks guaranteed to complete when scope ends

This feature evolves to preview in JDK 21 and reaches its final preview stage in JDK 24.

Record Patterns — The Beginning of Destructuring (JEP 405)

Record Patterns destructure Record components via pattern matching. It’s a concept similar to JavaScript’s destructuring assignment.

import java.util.List;

public class RecordPatternDemo {
    // Record representing coordinates
    record Point(int x, int y) {}
    // Record representing a line segment (composed of two points)
    record Line(Point start, Point end) {}

    // Decompose components with Record Pattern
    static String describePoint(Object obj) {
        // JDK 19 preview: Record Pattern (instanceof)
        if (obj instanceof Point(int x, int y)) {
            // x, y used directly — no separate accessor calls needed
            return String.format("Point(%d, %d) -> distance from origin: %.2f", x, y,
                Math.sqrt(x * x + y * y));
        }
        return "Not a Point";
    }

    // Nested Record Pattern — deep destructuring is possible
    static double lineLength(Object obj) {
        if (obj instanceof Line(Point(int x1, int y1), Point(int x2, int y2))) {
            // Line -> Point -> x, y destructured all at once
            double dx = x2 - x1;
            double dy = y2 - y1;
            return Math.sqrt(dx * dx + dy * dy);
        }
        return -1;
    }

    public static void main(String[] args) {
        Point p1 = new Point(3, 4);
        Point p2 = new Point(6, 8);
        Line line = new Line(p1, p2);

        System.out.println(describePoint(p1));
        // Point(3, 4) -> distance from origin: 5.00

        System.out.printf("Line length: %.2f%n", lineLength(line));
        // Line length: 5.00

        // Using with lists
        List<Object> shapes = List.of(
            new Point(0, 0),
            new Point(1, 1),
            new Line(new Point(0, 0), new Point(3, 4))
        );

        for (Object shape : shapes) {
            if (shape instanceof Point(int x, int y)) {
                System.out.printf("  Point: (%d, %d)%n", x, y);
            } else if (shape instanceof Line(Point s, Point e)) {
                System.out.printf("  Line: (%d,%d) -> (%d,%d)%n",
                    s.x(), s.y(), e.x(), e.y());
            }
        }
        //   Point: (0, 0)
        //   Point: (1, 1)
        //   Line: (0,0) -> (3,4)
    }
}

The real power of Record Patterns is unleashed when combined with Sealed Classes + switch pattern matching. After finalization in JDK 21, exhaustive switch that handles all subtypes without gaps becomes possible.

Pattern Matching for switch — Third Preview (JEP 427)

Switch pattern matching, first introduced in JDK 17, reached its third preview. The when keyword (guard pattern) was added, making conditional branching more natural.

import java.time.LocalDate;

public class SwitchGuardDemo {
    // Sealed interface + Record combination
    sealed interface Event permits Meeting, Deadline, Holiday {}
    record Meeting(String title, int attendees) implements Event {}
    record Deadline(String project, LocalDate dueDate) implements Event {}
    record Holiday(String name) implements Event {}

    static String describe(Event event) {
        return switch (event) {
            // when keyword adds guard conditions (JDK 19)
            case Meeting m when m.attendees() > 50
                -> "Large meeting: " + m.title() + " (" + m.attendees() + " people)";
            case Meeting m
                -> "Meeting: " + m.title() + " (" + m.attendees() + " people)";
            case Deadline d when d.dueDate().isBefore(LocalDate.now())
                -> "Overdue: " + d.project();
            case Deadline d
                -> "Upcoming deadline: " + d.project() + " (" + d.dueDate() + ")";
            case Holiday h
                -> "Holiday: " + h.name();
        };
        // Since it's a Sealed interface, no default needed — compiler checks all cases
    }

    public static void main(String[] args) {
        Event[] events = {
            new Meeting("Company Town Hall", 200),
            new Meeting("Team Standup", 8),
            new Deadline("API v2", LocalDate.of(2026, 3, 1)),
            new Deadline("Refactoring", LocalDate.of(2026, 12, 31)),
            new Holiday("Thanksgiving")
        };

        for (Event event : events) {
            System.out.println(describe(event));
        }
        // Large meeting: Company Town Hall (200 people)
        // Meeting: Team Standup (8 people)
        // Overdue: API v2
        // Upcoming deadline: Refactoring (2026-12-31)
        // Holiday: Thanksgiving
    }
}

With the when keyword, you can branch on detailed conditions within the same type. Readability is greatly improved compared to the previous preview’s && approach.

Foreign Function & Memory API — Preview (JEP 424)

A safe and modern native code calling API to replace JNI (Java Native Interface) was promoted to preview. It allows calling C library functions directly from Java and managing native memory safely.

It addresses JNI’s problems (boilerplate, lack of memory safety, platform-dependent builds) and is finalized in JDK 22.

I/O-Bound Throughput Innovation

Here’s what Virtual Threads bring in numbers:

ScenarioPlatform Thread (200 pool)Virtual Thread
Concurrent HTTP requests~200~10,000+
Handle other requests during DB query waitNot possible (thread occupied)Possible (auto-yield)
Memory usage (10,000 threads)~10GB~20MB
Code change requiredKeep existing codenewFixedThreadPool -> newVirtualThreadPerTaskExecutor

The key is achieving reactive-level throughput while using existing blocking code. Without adopting async frameworks like WebFlux or Kotlin Coroutines, you can simply swap Virtual Threads in a traditional thread-per-request model.

Summary

JDK 19 has few features but marks a turning point in Java concurrency programming.

  • Virtual Threads (preview): Maximize I/O-bound throughput with millions of lightweight threads. Finalized in JDK 21
  • Structured Concurrency (incubator): Manage concurrent task lifecycles structurally. Auto-propagate failure/cancellation
  • Record Patterns (preview): Destructure Record components via pattern matching. Nested destructuring also supported
  • Switch pattern matching (3rd preview): when guard conditions added for fine-grained branching
  • Foreign Function & Memory API (preview): Safe native calling API to replace JNI

JDK 19’s features are mostly in preview/incubator state, so it’s too early for production use. However, Virtual Threads and Structured Concurrency, which started in this version, are finalized in JDK 21 LTS and become the standard for Java concurrency programming. JDK 19 is the starting point of that revolution.

Was this article helpful?