Java 26 Preview: New JEPs and What They Mean for You
Transcript:
The next JDK 26 release includes 10 JEPs with new, improved, or removed features. Let’s look at all of them.
JEP 500 aims to prepare developers for the restriction of mutation of final fields in future releases. Final fields in Java represent an immutable state after they are assigned in the class initializer or in a constructor. They cannot be reassigned, and the expectation that a final field cannot be reassigned is important for reliability and even application performance. However, there are several APIs in Java that allow final fields to be reassigned at any time and by any code, and that undermines the whole point of final fields. With JEP 500, developers will receive warnings about the usage of deep reflection to mutate final fields. To avoid current warnings and future restrictions, developers will have to explicitly and selectively enable the mutation of final fields.
JEP 504 removes the Applet API. This includes the whole java.applet package, classes related to applets, and the remaining methods that reference the Applet API. Modern web browsers do not support applets anymore, so there is no reason to keep this API in the Java platform. Rest in peace, Applet API.
JEP 516 further improves the AOT cache introduced by Project Leyden in JDK 24. The AOT cache enables you to reduce startup and warm-up times of your applications by creating a cache with loaded and linked classes and method profiles. Previously, this cache was incompatible with ZGC, a low-latency garbage collector. Now it can be used with all garbage collectors, including ZGC, so you no longer have to choose between low latency and fast startup.
JEP 517 updates the Java HTTP Client API to support the HTTP/3 protocol. This protocol was standardized in 2022 and is supported by most modern browsers. Java applications using HTTP/3 can benefit from a more reliable transport and potentially faster handshakes. HTTP/2 remains the default version of the HTTP Client API in Java. Developers can use HTTP/3 by setting it explicitly as the version of the HTTP client object. If the target server does not support HTTP/3, the request will be transparently downgraded to HTTP/2 or even HTTP/1.
JEP 522 aims to improve the throughput of Java applications that use G1GC by reducing G1’s synchronization overhead. G1GC keeps track of object references so that it can update them efficiently after objects are moved. Some applications update references so frequently that G1GC has to use background optimizer threads. These threads must synchronize with application threads to avoid interfering with each other, and this coordination slows down G1 write barriers. This JEP addresses the problem by allowing application threads and G1 optimizer threads to work on separate copies of the tracking data and swap them when needed. This boosts throughput without changing how users interact with G1GC.
PEM encodings of cryptographic objects provide an API for encoding objects that represent certificates, cryptographic keys, and certificate revocation lists into the Privacy-Enhanced Mail format, or PEM, and for decoding them back into objects. JEP 524 revises this feature with several changes, including renamed classes and methods.
Structured concurrency was first introduced in Java 19. Its goal is to improve the experience of working with concurrency in Java and help developers write more readable, maintainable, and reliable code. The key idea is tying the lifetime of subtasks to a specific scope with clear entry and exit points, namely the task’s code block. This way, errors, cancellations, and observability follow a clear enforced parent-child structure. If one subtask fails, others are automatically cancelled. JEP 525 revises this feature with minor changes to gather additional feedback.
Lazy constants are objects holding immutable data. Like final fields, they are treated as constants by the JVM and allow for similar optimizations. Unlike final fields, they do not have to be initialized at the moment of creation. This allows applications to initialize incrementally and start faster. Lazy constants were first introduced in JDK 25 as stable values. JEP 526 gives them a new name and shifts their purpose toward higher-level use cases, removing low-level methods. Some features were also removed: lazy collection helpers are now exposed as List of Lazy or Map of Lazy, and computed null values are no longer allowed.
JEP 529 re-incubates the Vector API without significant changes. The Vector API was first introduced in JDK 16. It enables expressing vector computations that reliably compile to optimal vector instructions at runtime. This API will remain incubating until the necessary features of Project Valhalla are introduced as preview features. After that, the Vector API will be promoted to preview.
JEP 530 introduces two important changes to the feature that allows using primitive types in patterns, instanceof, and switch. First, the JEP tightens the rules the compiler uses to decide when a conversion is guaranteed not to lose information. The feature now clearly covers always-safe conversions such as byte to int or int to double, as well as constant values that are safe to convert, for example the literal 42 to int. The second change introduces stricter dominance checks for primitive types in switch expressions. The switch now rejects case labels that can never be reached because an earlier case already matches all possible values of a later case.
And these were the 10 JEPs of JDK 26. You can get early access builds of JDK 26 on the official OpenJDK website if you want to experiment with them. If this video was useful to you, don’t forget to like it, subscribe to the channel, and until next time.
