JDK 26: Performance Optimizations for Containerized Java Workloads

JDK 26 may appear skippable at first glance. It’s not an LTS release, and zero preview features have graduated to final status. But dismissing it would be a mistake. This release delivers measurable performance gains, especially for containerized workloads—the modern standard for enterprise Java deployments.

What’s New in JDK 26

Simon Ritter, Deputy CTO at Azul, describes JDK 26 as “not one of the bigger releases, but also not one of the smallest.” The release includes 10 JEPs (JDK Enhancement Proposals), with several focused on improving runtime performance and developer productivity.

No Features Made Final

A notable characteristic: no preview features or incubator modules have been promoted to final status. This is unusual but reflects the ongoing development of major projects like Loom and Valhalla, which require more iteration before finalization.

Performance Improvements for Containerized Workloads

G1 Garbage Collector Optimizations

The G1 garbage collector receives synchronization improvements that reduce time-to-safe-point. When garbage collection occurs, the JVM must reach a “global safe point” where all threads are paused at a common location. The overhead of synchronizing threads to reach this point has been reduced, minimizing pause times and improving throughput.

This matters particularly for containerized environments where:

• Multiple JVM instances share the same host
• Predictable latency is critical
• Resource constraints make efficient GC essential

HTTP/3 API

JDK 26 introduces a new HTTP/3 API. HTTP/3 switches from TCP to UDP (using QUIC protocol), offering:

UDP is inherently unreliable, but HTTP/3 builds reliability on top of it. The result is better performance for distributed microservices where latency matters.

Language and API Enhancements

Making Final Truly Final

Java’s final fields have always had a loophole: reflection can modify them. This complicates JVM optimization because the runtime must account for potential reflection-based changes.

JDK 26 moves toward making final genuinely immutable. Once set, a final field cannot be changed—even through reflection. This enables:

• More aggressive compiler optimizations
• Better inlining decisions
• Predictable runtime behavior

Lazy Constants (Previously Stable Values)

Lazy constants provide controlled initialization timing for fixed values. Unlike regular final fields, lazy constants let developers specify when initialization occurs, which can improve startup performance and memory efficiency.

Primitive Types in Patterns

Pattern matching for instanceof and switch now supports primitive types. This bridges the gap between primitives (int, long) and their wrapper classes (Integer, Long), though edge cases around precedence and ordering required careful handling.

Project Loom: Structured Concurrency

Structured concurrency remains in preview, continuing Project Loom’s mission to simplify multi-threaded programming. Writing correct concurrent code is notoriously difficult; structured concurrency provides a model where:

• Tasks have clear lifecycles
• Child threads are bounded by parent scope
• Error handling is predictable

Timeline: Simon expects structured concurrency to become final in JDK 27 or JDK 28 (the next LTS). The API saw no significant changes in JDK 26, suggesting it’s nearing completion.

Project Valhalla: Vector API

The Vector API enters its 11th incubator iteration. The delay stems from its dependency on other Valhalla components—specifically value types.

What Vector API Enables

Vector API leverages SIMD (Single Instruction, Multiple Data) capabilities of modern CPUs:

A single instruction can operate on multiple data elements simultaneously. For numerically intensive workloads—AI inference, scientific computing, image processing—this delivers substantial speedups.

Why the Delay?

Vector API depends on value types from Project Valhalla. Value types will allow:

• Collections of primitives (e.g., List<int> instead of List<Integer>)
• More efficient memory layout
• Reduced indirection and boxing overhead

Once Valhalla’s core components ship (expected within a year), Vector API can finalize.

Applet API Removed

JDK 26 removes the Applet API entirely. Applets made Java famous in 1995 but have been obsolete for years:

• Browsers discontinued plugin support
• JDK 11 removed the browser plugin
• The API remained in the class library for compatibility

This is cleanup, not functionality loss. No modern cloud or containerized application uses applets.

Technical Deep Dive

Structured Concurrency: Code Example

Structured concurrency simplifies managing concurrent tasks. Here’s how it works:

1
// Before: Managing threads manually is error-prone
2
ExecutorService executor = Executors.newCachedThreadPool();
3
try {
4
    Future<String> user = executor.submit(() -> fetchUser(id));
5
    Future<List<Order>> orders = executor.submit(() -> fetchOrders(id));
6
    // What if fetchUser fails? Orders continues running...
7
    return new Response(user.get(), orders.get());
8
} finally {
9
    executor.shutdown();
10
}

1
// JDK 26: Structured Concurrency (Preview)
2
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
3
    Supplier<String> user = scope.fork(() -> fetchUser(id));
4
    Supplier<List<Order>> orders = scope.fork(() -> fetchOrders(id));
5

6
    scope.join();           // Wait for all tasks
7
    scope.throwIfFailed();  // Propagate exceptions
8

9
    return new Response(user.get(), orders.get());
10
}

Run with: java --enable-preview --source 26 MyApp.java

Vector API: SIMD Operations

The Vector API enables data-parallel operations on CPU vector registers:

1
static final VectorSpecies<Float> SPECIES = FloatVector.SPECIES_256;
2

3
void scalarComputation(float[] a, float[] b, float[] c) {
4
    for (int i = 0; i < a.length; i++) {
5
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
6
    }
7
}
8

9
void vectorComputation(float[] a, float[] b, float[] c) {
10
    int i = 0;
11
    int upperBound = SPECIES.loopBound(a.length);
12
    for (; i < upperBound; i += SPECIES.length()) {
13
        var va = FloatVector.fromArray(SPECIES, a, i);
14
        var vb = FloatVector.fromArray(SPECIES, b, i);
15
        var vc = va.mul(va)
16
                   .add(vb.mul(vb))
17
                   .neg();
18
        vc.intoArray(c, i);
19
    }
20
    // Handle remaining elements
21
    for (; i < a.length; i++) {
22
        c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f;
23
    }
24
}

Compile with: javac --add-modules jdk.incubator.vector VectorDemo.java

Performance impact: On a 256-bit AVX register, 8 floats process simultaneously—potential 8x speedup for numerically intensive loops.

Primitive Types in Patterns

Pattern matching now works with primitives:

1
// JDK 26: Primitive pattern matching (Preview)
2
Object value = 42;
3

4
if (value instanceof int i) {
5
    System.out.println("Integer: " + i);
6
} else if (value instanceof long l) {
7
    System.out.println("Long: " + l);
8
}
9

10
// Switch with primitive patterns
11
switch (value) {
12
    case int i -> System.out.println("int: " + i);
13
    case long l -> System.out.println("long: " + l);
14
    case float f -> System.out.println("float: " + f);
15
    case double d -> System.out.println("double: " + d);
16
    default -> System.out.println("other");
17
}

HTTP/3 Client

The new HTTP/3 client uses QUIC over UDP:

1
HttpClient client = HttpClient.newBuilder()
2
    .version(HttpClient.Version.HTTP_3)
3
    .build();
4

5
HttpRequest request = HttpRequest.newBuilder()
6
    .uri(URI.create("https://example.com/api"))
7
    .GET()
8
    .build();
9

10
HttpResponse<String> response = client.send(
11
    request,
12
    HttpResponse.BodyHandlers.ofString()
13
);

Note: HTTP/3 requires server support. Most CDNs and cloud providers now support it.

JVM Flags for Containerized Workloads

Key JVM options for running JDK 26 in containers:

1
# Container-aware resource limits (enabled by default in JDK 26)
2
java -XX:+UseContainerSupport \
3
     -XX:MaxRAMPercentage=75.0 \
4
     -XX:InitialRAMPercentage=50.0 \
5
     -Xlog:gc*:file=/var/log/gc.log:time,tags \
6
     -jar app.jar

1
# G1 GC tuning for low latency
2
java -XX:+UseG1GC \
3
     -XX:MaxGCPauseMillis=100 \
4
     -XX:G1HeapRegionSize=16m \
5
     -XX:+ParallelRefProcEnabled \
6
     -jar app.jar

1
# Enable preview features
2
java --enable-preview \
3
     --add-modules jdk.incubator.vector \
4
     -jar app.jar

Ahead-of-Time Class Loading (JEP 483)

JDK 26 introduces AOT class loading and linking, reducing startup time:

1
# Create AOT cache during build
2
java -XX:AOTCache=app.aot -cp myapp.jar com.example.Main --AOT-cache-init
3

4
# Use AOT cache at runtime
5
java -XX:AOTCache=app.aot -cp myapp.jar com.example.Main

This is particularly valuable for serverless and microservices where cold starts matter.

Should Enterprise Teams Adopt JDK 26?

For teams running containerized workloads with CI/CD pipelines:

The performance improvements are “free” for teams already updating container images regularly. If you’re on JDK 25 and can tolerate a non-LTS release, JDK 26 offers tangible benefits.

Summary

JDK 26 proves that a release without headline-grabbing features can still matter. The G1 garbage collector improvements, HTTP/3 support, and progress toward immutable final fields all contribute to better performance for modern deployment patterns.

For containerized enterprise Java, the question isn’t whether JDK 26 has new features—it’s whether the performance gains justify an upgrade. For teams already running frequent deployments, the answer is likely yes.

References

• JDK 26 JEPs
• Project Loom
• Project Valhalla
• Azul

This article was written by opencode (GLM-5), based on content from: https://www.youtube.com/watch?v=Sg_SEyZ0ntE

Related Articles

Quarkus vs Helidon for GraalVM-Native Java: A Practical, Developer-Centric Comparison

Jan 8, 2026