With the release of JDK 26, which arrived March 17, we’ve now seen 17 versions of Java delivered under the time-based six-month release cadence. Nobody can call this anything other than a huge success for Java. In the last eight years, we’ve seen the Java platform move forward faster than at any time in its history. In addition, the faster release cadence has made preview features and incubator modules a practical reality. This allows fully developed features to be tested by developers, with feedback incorporated before the feature is finalized. Within practical limits, Java developers get exactly what they want in new features.

As an interesting note, JDK 26 is the first Java version in which no preview features have been made final. What then does JDK 26 deliver?

There are 10 JDK Enhancement Proposals (JEPs), which are the mechanism for defining new features in the OpenJDK project. This is slightly below average, but it’s worth noting that it is not a long-term support (LTS) release. LTS versions of Java are the ones that OpenJDK distributions commit to providing extended maintenance and support for, so they are more likely to be used in production. This does not mean JDK 26 is not production quality; if you use a CI/CD pipeline with frequent deployments, JDK 26 will be great for running your applications.

Let’s break down the new features by category: the Java language, the libraries, and the runtime.

Improvements in the Java language

The only language-specific feature is the continued development of primitive types in patterns, instanceof, and switch (JEP 530), which is in its fourth preview. Although Java is an object-oriented language, Java does not treat everything as an object; it has primitive values to improve performance. This JEP allows primitive types to be used in places where previously, you would have needed a reference type. Changes have been made to resolve issues found when combining primitive types (like int) with reference types (like the wrapper class Integer).

Improvements in the Java libraries

The bulk of the changes in JDK 26 are in the libraries.

• JEP 517: HTTP/3 for the HTTP Client API. The HTTP Client API has been enhanced to include support for the latest HTTP/3 protocol. Rather than using TCP, which HTTP/2 and earlier versions rely on, HTTP/3 uses the UDP-based QUIC protocol. This delivers better performance without requiring any code changes, other than specifying the protocol when creating the connection.
• JEP 524: PEM Encoding for Cryptographic Objects. Cryptographic objects such as public keys, private keys, certificates, and certificate revocation lists are often transmitted using e-mail, and the Privacy-Enhanced Mail (PEM) format is ideal for this. This JEP adds a concise API for converting between PEM text and cryptographic objects, and back again.
• JEP 525: Structured Concurrency. Writing cooperative multi-threaded code is notoriously difficult to get right. Over its history, Java has added many features to make this easier, from the Concurrency Utilities APIs to the ForkJoin framework and, more recently, Virtual Threads. Structured Concurrency adds to this toolbox, treating groups of related tasks running in different threads as single units of work. This allows streamlined error handling and cancellation, improving reliability and enhancing observability. Developers will be familiar with the approach, since it is like the try-with-resources syntax.
• JEP 526: Lazy Constants. This was previously called “stable values,” but the new name better reflects the goal of this feature: to provide objects that hold unmodifiable data. Although Java has final fields, Lazy Constants offer greater flexibility in the timing of their initialisation.
• JEP 529: The Vector API. This JEP is now incubating for the eleventh time, which is a record for a JEP. As this API is part of the larger Project Valhalla, it will not be finalized until more of that project is incorporated into the Java platform. In this API, vectors refer to the very wide registers available in modern processors. Specific instructions allow for multiple values to have the same operation applied to them across these registers in a single clock cycle, greatly improving performance for numerically intensive operations (like AI). Although the JIT compiler will auto-vectorize code it recognizes, it is unable to do this in all situations where vectors can be used. With the Vector API, a developer can explicitly specify how they want the vector operations to be used by the JIT compiler.
• JEP 504: Remove the Applet API. Applets were what really set Java on its road to success when it was first launched. However, browsers (where Applets were used) have long since moved on, and no mainstream browser supports the Java Plugin required to run Applets. The Java Plugin was removed from Oracle JDK 11, is not part of the OpenJDK project, and remains closed-source. The Applet API is the final remaining component and has been deprecated for removal since JDK 17.

Improvements in the Java runtime

Finally, we have runtime changes:

• JEP 500: Prepare to make final mean final. As mentioned earlier, Java has the concept of final fields, whose value can be set only once. Although a final field cannot be modified simply by assigning it a new value, it is still possible to change its value in certain cases through a feature called deep reflection. This limits what the JVM can do to optimize performance, since it still needs to accommodate the possibility of a change. This JEP makes it clear to developers that in a future release, they will no longer be able to use deep reflection in this way and should change their code in preparation.
• JEP 516: Ahead-of-time (AOT) object caching with any GC. This is part of the larger OpenJDK Project Leyden, whose goal is to reduce the time an application takes to warm up to its optimum performance level. The need to identify frequently used code and compile it as the application is running is why performance does not start at full speed. This JEP enables the AOT cache, which is data about loaded and initialized classes, to work with any garbage collector. This was necessary because the ZGC collector did not work with the AOT cache.
• JEP 522: G1 GC improve throughput by reducing synchronization. G1 is the default garbage collector in the HotSpot VM and works well in many situations. This JEP improves efficiency for this collector by reducing the amount of synchronization required between the GC and application threads. This is transparent to application code.

In conclusion, despite not including as many JEPs as some releases, there are still useful and interesting new additions to the Java platform. Although JDK 26 is not an LTS version, developers should still test their applications with this release to avoid accumulated issues when JDK 29, the next LTS release, appears next year.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.