The Core Concept: JDK 26 includes 10 JDK Enhancement Proposals focused on language evolution and JVM optimization, but zero preview features or incubator modules graduated to final status, raising questions about whether enterprise teams should adopt this non-LTS release.

The Guest: Simon Ritter, Deputy CTO at Azul

The Bottom Line:
• Making final fields truly immutable by removing deep reflection capabilities unlocks aggressive JVM compiler optimization strategies

[expander_maker]

Speaking with TFiR, Simon Ritter of Azul defined the current state of JDK 26 development and explained why the 10 JDK Enhancement Proposals represent meaningful progress despite the absence of finalized features.

WHAT ARE JDK ENHANCEMENT PROPOSALS AND WHY DOES JDK 26 HAVE ZERO FINAL FEATURES?

JDK Enhancement Proposals are the formal mechanism for defining specific features included in each Java Development Kit release. JDK 26 contains 10 JEPs addressing language evolution, JVM performance, and legacy code removal, but none of the preview features or incubator modules graduated to final status in this release cycle.

“JDK 26 is not a Long Term Support release, but it still contains new features and changes. Looking at the list of new additions, it is neither one of the biggest releases nor one of the smallest. One thing of note about this release in particular is that no preview features or incubator modules have been made final.”

The 10 JEPs cover structured concurrency for multi-threaded code simplification, lazy constants for deferred value assignment, making final fields truly immutable by eliminating deep reflection, Vector API iteration 11 as part of Project Valhalla, primitive types in pattern matching, Applet API removal, G1 garbage collector synchronization improvements, PEM encoding for cryptographic objects, and HTTP/3 API support.

Structured Concurrency and Multi-Threaded Code Reliability

Structured concurrency remains in preview status as part of Project Loom’s effort to simplify cooperative multi-threaded programming. The feature addresses the difficulty Java developers face when coordinating multiple threads in production applications.

“Structured concurrency is a way that the language is evolving to make life easier for people to develop multi-threaded code. 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.”

Making Final Fields Truly Immutable and JVM Compiler Optimization

JDK 26 introduces changes to enforce true immutability for final fields by removing the ability to modify them using deep reflection. This architectural shift enables JVM compiler teams to apply more aggressive optimization strategies that were previously blocked by the theoretical possibility of field mutation.

“There is this idea in Java of final fields. A final field means that you set it once and cannot change it. Or at least that’s the theory. The reality is that 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 when it comes to optimizing code to its maximum potential. What they want to do is make final really mean final, so that 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 out of the JVM.”

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

“Lazy constants is a similar concept in the sense that it’s about having fixed values associated with a name, but the reason we want lazy values in addition to final fields is that lazy values give you more control over when that value is assigned, and that can be quite significant in terms of the way that  the language works and the way programs handle things.”

Vector API Iteration 11 and Project Valhalla Timeline

The Vector API entered its 11th incubation iteration in JDK 26, with finalization deliberately deferred until Project Valhalla’s value types reach completion. Project Valhalla represents a fundamental change in how the JVM handles object layout and primitive type integration with collections.

“The Vector API is part of Project Valhalla. It’s in its 11th iteration now, so it has been going through a long gestation process. There’s no real reason for it to go through such an extended set of changes. There’s not a lot of work going on there. It’s more to do with the fact that the developers have said that until other parts of Project Valhalla come out, which may be another year, as I would expect, then we won’t see the Vector API become final.”

Project Valhalla will enable developers to use primitives directly in collections, eliminating the current requirement for wrapper classes and improving memory efficiency and performance for numerically intensive workloads.

Primitive Types in Pattern Matching and Edge Case Analysis

JDK 26 extends pattern matching support to include primitive types alongside reference types in instanceof and switch expressions. This expansion required extensive edge case analysis to handle scenarios where primitives and wrapper classes like int and Integer are mixed in pattern matching logic.

“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. They’ve had to go through and there’s a lot of edge cases that need to be analyzed and corrected for that.”

Applet API Removal After Three Decades

JDK 26 completes the removal of the Applet API, eliminating legacy code that has been deprecated since browser plugin support was discontinued in JDK 11. The removal reflects Java’s evolution from its 1995 desktop origins to its current server-side and cloud-native identity.

“Applets were the thing that really made Java famous back in 1995 when it was first launched. They’ve never really been popular since the first few years. Java has very much succeeded on the server side, not on the desktop. Everybody uses JavaScript, CSS, and that kind of thing. None of the browsers support applets anymore. The browser plugin was discontinued in JDK 11, but they left the API for applets in the class libraries, and now they’re finally tidying that up and removing it completely.”

G1 Garbage Collector Synchronization and PEM Encoding

Performance improvements in JDK 26 include G1 garbage collector optimizations that reduce synchronization overhead when reaching global safe points, improving efficiency for containerized workloads. Additionally, PEM encoding support for cryptographic objects simplifies encrypted email handling by providing direct API access to cryptographic key management.

“There’s some improvements around what’s called the G1 garbage collector. They’re reducing synchronization that’s associated with that. It’s quite a low-level feature, but it’s designed to improve the efficiency of the garbage collector if you’re using that particular one. There’s also the inclusion of what is called PEM encoding of cryptographic objects. If you want to send email and encrypt that email, there’s now an API that allows you to do that directly so you can handle the cryptographic keys from your application code.”

HTTP/3 API for High-Performance 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. The architectural shift delivers performance benefits for distributed systems.

“Another small thing is an API specifically for HTTP/3. This is high performance. Rather than using TCP as the connection protocol, it uses UDP in a reliable way, but again it’s just about improving the performance of things.”

Broader Context: JDK 26 Performance Gains for Containerized Workloads

In the full TFiR interview, Ritter explained how JDK 26’s cumulative performance improvements jusfsimontify adoption for containerized Java workloads despite its non-LTS status. The G1 garbage collector optimizations reduce synchronization overhead by accelerating global safe point coordination, which directly impacts pause times in production environments.

“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. 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.”

For teams operating CI/CD pipelines that already update container images frequently, adopting JDK 26 becomes practical because version management overhead is already absorbed into existing workflows. The aggregated effect of language evolution features, JVM compiler optimizations, and garbage collector improvements translates to measurable performance gains.

Watch the full TFiR interview with Simon Ritter here.

[/expander_maker]