Here’s the thing: you’re trying to write code, and suddenly, a final field you thought was immutable isn’t. That’s the gnawing inconsistency Java 26 is finally addressing. For years, the ability to meddle with final fields via reflection has been a quiet thorn in the side of developers, a loophole that actively hinders compiler optimizations and breaks the very semantic promise of immutability.
Now, Java 26 is taking a firm, albeit phased, stand. The Java Enhancement Proposal (JEP) 525, aptly titled ‘Strictly-Final Fields,’ isn’t about removing reflection entirely – that would be a seismic, and frankly, impractical, undertaking. Instead, it’s about reining in the abuse. Starting with this release, attempts to modify final fields will trigger special warnings. The roadmap is clear: future versions will escalate this to outright exceptions, forcing a reckoning with outdated codebases and ensuring that when you declare something final, it stays final.
This isn’t just about correctness; it’s about performance. Compilers have been hobbled, unable to perform vital optimizations like constant folding when there’s even a chance a final variable’s value could be altered. By closing this door, Java 26 unlocks potential performance gains, aligning runtime behavior with developer intent and freeing up the JVM’s optimization engines.
The Applet Era Is Officially Over
And then there were none. The official death knell for Java Applets has finally sounded with Java 26. This isn’t a surprise; it’s been a long, drawn-out process, a slow fade that began as far back as 2017 when browsers started ditching support. JDK 9 marked them as Deprecated. JDK 11 removed the Appletviewer. JDK 17 marked the API with forRemoval=true. Last year, JDK 24 saw the removal of SecurityManager, which was crucial for applet security. Now, in 2026, the final nail is hammered in.
Applets were never truly understood by the world, disappearing before their time.
It’s a bit melancholy, isn’t it? These relics of a bygone web era, born in a time of dial-up and early Java integration, finally meet their end. They were a noble attempt, perhaps, but ultimately outpaced by the web’s own evolution and the rise of more dynamic, secure technologies. Their departure simplifies the Java ecosystem and signals a clean break from a chapter that, for most developers, has been closed for years.
HTTP/3 Joins the Client
The HttpClient introduced in Java 11 was a welcome upgrade, replacing the aging HttpUrlConnection. Now, Java 26 brings it up to speed with the latest web protocols by adding support for HTTP/3. With over a third of web servers already supporting HTTP/3 according to W3Techs, this move is not just about staying current but about embracing a protocol designed to fix fundamental issues like head-of-line blocking and improve handshake speeds.
To use HTTP/3, developers need to explicitly set the version during client configuration:
var client = HttpClient.newBuilder()
.version(HttpClient.Version.HTTP_3) // <=
.build();
Or on a per-request basis:
var request = HttpRequest.newBuilder(URI.create("https://openjdk.org/"))
.version(HttpClient.Version.HTTP_3) // <=
.GET().build();
The good news is that if a server doesn’t support HTTP/3, the client will gracefully fall back to HTTP/2 and then HTTP/1.1. This ensures compatibility while encouraging adoption of the faster, more reliable protocol.
Previewing Lazy Constants (JEP 519)
JEP 519, ‘Lazy Constants,’ is back for its second preview, building on the foundation of JEP 502’s Stable Values. The core idea remains: initialize static constants only when they are actually needed, rather than at class load time. This offers a significant boost to application startup performance, especially for classes with many constants that might never be invoked.
The API has seen some refinement. StableValue has been renamed to LazyConstant, and low-level methods have been pruned, focusing on high-level factories. Notably, null is no longer permitted as a computed value, a move likely aimed at preventing further inconsistencies and supporting deeper compiler optimizations. This iterative approach to preview features allows developers to provide feedback and allows the JDK team to sculpt a more strong and useful API before its eventual finalization.
Vector API Continues to Mature (JEP 528)
The Vector API, designed to unlock data-level parallelism and CPU-level vector computation through SIMD instructions, continues its journey toward stability. JEP 528, the sixth preview of the Vector API, refines this powerful tool for high-performance computing. The goal is to offer raw computational power through a developer-friendly API, bridging the gap between low-level hardware capabilities and high-level Java code. This ongoing development suggests a strong commitment to empowering Java for data-intensive workloads.
One Unique Insight
What’s truly fascinating about Java 26 isn’t just the addition of HTTP/3 or the streamlining of final fields; it’s the underlying philosophical shift it represents. For so long, Java’s strength was its ubiquity and a certain degree of inertia. Now, with its rapid six-month release cadence, it’s behaving less like a lumbering titan and more like a nimble competitor. The aggressive pruning of applets, while overdue, signals a deliberate shedding of legacy, a willingness to let go of what no longer serves the ecosystem in favor of embracing modernity. It’s a proactive stance, a declaration that Java intends to remain at the cutting edge, even if it means occasionally leaving old friends behind. This isn’t just evolution; it’s a strategic recalibration.
