In a recent TFiR interview, Swapnil Bhartiya spoke with Simon Ritter, Deputy CTO at Azul, about why JDK 26 represents a significant performance opportunity for enterprise Java teams despite its non-LTS status and lack of finalized features.

JDK 26 ENHANCEMENT PROPOSALS AND PERFORMANCE ARCHITECTURE

JDK 26 includes 10 JDK Enhancement Proposals focused on incremental performance improvements and developer productivity. While no preview features or incubator modules graduated to final status in this release, the cumulative effect of G1 Garbage Collector optimizations, HTTP/3 protocol support, and JVM-level efficiency improvements translates to measurable gains for containerized workloads and microservices architectures.

“If you’re looking to improve the performance of your applications, just keeping up to date with the latest version is always going to give you a free performance improvement. The OpenJDK engineers are always looking at ways to improve the efficiency of the way that the JVM works.”

Structured Concurrency and Project Loom Timeline

Structured concurrency remains in preview status as part of Project Loom’s ongoing development. The feature simplifies multi-threaded code development by providing cooperative threading primitives that reduce complexity and improve reliability.

“It’s notoriously difficult to create cooperative multi-threaded code, so this is a way of trying to ease that process and make code more reliable. I would think structured concurrency may be a full feature in the next release. Certainly by 2028, I’m sure structured concurrency will be in there.”

Making Final Fields Truly Immutable

JDK 26 introduces changes to enforce true immutability for final fields by eliminating deep reflection capabilities that previously allowed modification of supposedly immutable values. This change enables JVM compiler teams to apply more aggressive optimization strategies.

“Although from a language perspective you can’t change a final field, you can still change it if you use deep reflection. That makes life difficult for the JVM in terms of optimizing the code to the maximum level that it can. What they want to do is make final really mean final so once you set a field to a particular value, you cannot change it at all. That way we can optimize things more and get better performance.”

Lazy constants complement this change by providing developers fine-grained control over when constant values are assigned, addressing use cases where deferred initialization improves performance or simplifies architecture.

G1 Garbage Collector Synchronization Optimization

The G1 Garbage Collector improvements in JDK 26 focus on reducing synchronization overhead when reaching global safe points, where all application threads must pause for garbage collection operations.

“What they’re actually doing in this JEP is to reduce the amount of synchronization that’s necessary so you can reach that global safe point quicker, and that then reduces the time that you have to wait for the application threads to do their work and reduce the overhead on that.”

For containerized Java workloads running in Kubernetes or Docker environments with CI/CD pipelines that already update container images frequently, adopting JDK 26 becomes practical because teams are already managing regular version updates.

HTTP/3 API for Distributed Microservices

JDK 26 introduces HTTP/3 protocol support, switching from TCP to UDP as the underlying transport mechanism while maintaining reliability guarantees required for web and microservices communication.

“HTTP/3 works by switching from using TCP as the high-level protocol to using UDP. UDP allows you to be more efficient in terms of the way you send packets. TCP is what’s called a reliable protocol, meaning that you know the packets you’re sending will be received in the order that you send them in. UDP is basically an unreliable protocol, which means if packets get lost, that’s too bad, and packets may not arrive in the right order. HTTP/3 has to build on top of using UDP to give you that reliability.”

This architectural shift delivers performance benefits for high-throughput distributed systems while preserving the ordering and delivery guarantees applications require.

Vector API 11th Iteration and Project Valhalla Dependency

The Vector API remains in incubation for its 11th iteration, with finalization deliberately deferred until Project Valhalla’s value types reach completion.

“Vector API is part of Project Valhalla. Valhalla is the idea of value types in Java. It’s a big change in terms of how the JVM works underneath. It’s going to allow better efficiency and better performance because of the way that we can lay out objects. From a coding point of view, it will allow you to have a collection where you can put primitives into a collection. Can’t do that at the moment, but Project Valhalla will allow you to do that.”

The Vector API enables single instruction multiple data processing, allowing developers to leverage CPU SIMD capabilities for numerically intensive workloads including AI and machine learning applications.

“You’ve got these very wide registers. You can load up a number of elements from an array into those very wide registers. They could be 128 bits wide, 256, 512 bits is the widest you get on Intel. ARM goes all the way up to 4,000 bits in some processors. That allows you to apply the same operation to all of those elements in a single clock cycle. If you want to add three to each of the elements, you can do that in a single clock cycle. That’s very efficient if you’re doing numerically intensive operations.”

Primitive Types in Pattern Matching

JDK 26 extends pattern matching support to include primitive types in addition to reference types, addressing edge cases that arise when mixing primitives with wrapper classes like int and Integer in instanceof and switch expressions.

“Having introduced pattern matching for instanceof and switch in earlier versions of Java, that only worked with full types. What they’ve now allowed you to do is use primitives in those things. But when you put primitives in there and you mix them with types and wrapper classes, things can get a little complicated in terms of trying to identify which precedents you have and how things are ordered.”

Applet API Removal and Cloud-Native Identity

JDK 26 completes the removal of the Applet API, finalizing a deprecation process that began when browser plugin support was discontinued in JDK 11.

“Applets were the thing that really made Java famous back in 1995 when it was first launched. They’ve never really been popular after the first few years. Java has very much succeeded on the server side, not on the desktop. None of the browsers support applets anymore. It makes perfect sense to remove the Applet API because nobody in their right mind is going to try and write an applet using JDK 26.”

The removal reflects Java’s evolution toward cloud-native workloads and server-side enterprise applications, eliminating legacy code that no longer serves production use cases.

PEM Encoding for Cryptographic Objects

JDK 26 adds an API for PEM encoding of cryptographic objects, simplifying encrypted email handling by providing direct access to cryptographic key management from application code.

Performance Gains from Incremental JVM Improvements

Beyond the 10 major JDK Enhancement Proposals, JDK 26 includes numerous smaller optimizations, bug fixes, and efficiency improvements contributed by OpenJDK engineers.

“Even though I’ve outlined 10 JEPs, there’s also a whole set of other changes which come from very small things that may be bugs that are reported or things that people have identified as a way to improve efficiency or performance. All those things collected, once they’re delivered into the JDK, that means you get a bump in performance.”

For teams operating containerized Java applications with established CI/CD pipelines, the aggregated performance improvements justify adopting JDK 26 despite its non-LTS designation.