Java 26’s initial release candidate has been released, with its full public launch anticipated in March.
The Java Development Kit (JDK) 26, scheduled for its stable release on March 17, 2026, has officially entered its first release candidate (RC) phase. This RC period is dedicated to addressing critical bugs, following the finalization of its feature set back in December.
JDK 26 is set to include these 10 official features: a fourth preview for primitive types in patterns, instanceof, and switch; ahead-of-time object caching; the eleventh incubation of the Vector API; second previews for both lazy constants and PEM (Privacy-Enhanced Mail) encodings of cryptographic objects; a sixth preview of structured concurrency; warnings regarding deep reflection used to modify final fields; enhanced throughput via reduced synchronization in the G1 garbage collector (GC); HTTP/3 support for the Client API; and the deprecation of the Java Applet API.
Unlike JDK 25, a Long-Term Support (LTS) release from September 16 with multi-year Premier support, JDK 26 is a short-term Java release offering six months of Premier-level support. Early-access versions of JDK 26 can be found at https://jdk.java.net/26/. The project initiated its first rampdown phase in early December, followed by a second in mid-January, with a second release candidate slated for February 19.
The newest addition, primitive types in patterns, instanceof, and switch, aims to improve pattern matching by incorporating primitive types across all pattern contexts and extending instanceof and switch to operate with all primitive types. This feature, now in its fourth preview, was previously featured in JDK 23, 24, and 25. Its objectives include facilitating consistent data exploration through type patterns for all types, ensuring type patterns align with instanceof, making instanceof compatible with safe casting, and allowing pattern matching to utilize primitive types in both nested and top-level scenarios. The enhancements in this fourth preview refine the definition of unconditional exactness and introduce stricter dominance checks within switch constructs. These updates empower the compiler to detect a broader spectrum of coding errors.
Ahead-of-time object caching is set to boost the HotSpot JVM’s startup and warm-up performance, making it compatible with any garbage collector, including the low-latency Z Garbage Collector (ZGC). This improvement is achieved by enabling the sequential loading of cached Java objects into memory from a universal, GC-independent format, rather than directly mapping them in a GC-specific manner. The key objectives for this feature are to ensure seamless integration of all garbage collectors with the AOT (ahead-of-time) cache from Project Leyden, to decouple the AOT cache from specific GC implementation details, and to guarantee that utilizing the AOT cache doesn’t negatively affect startup times compared to prior versions.
Now in its eleventh incubation, the Vector API provides a means to define vector computations that consistently translate into optimized vector instructions on compatible CPUs during runtime. This results in significantly better performance than comparable scalar computations. The Vector API has been an incubating feature since JDK 16, released in March 2021. Its design emphasizes clarity, conciseness, platform independence, dependable compilation and execution on x64 and AArch64 architectures, and effective graceful degradation. Ultimately, the Vector API aims to harness the improvements to the Java object model brought forth by Project Valhalla.
JDK 26 will also include a further preview of the API for lazy constants, a feature first seen in JDK 25 through its stable values capability. Lazy constants are immutable data objects recognized as genuine constants by the JVM, thus allowing the same performance enhancements typically associated with declaring a field final. A key benefit of lazy constants is the increased control over their initialization timing.
The second preview of PEM (Privacy-Enhanced Mail) encodings proposes an API for converting cryptographic objects—such as keys, certificates, and certificate revocation lists—into the PEM transport format, and subsequently decoding them back into their original object forms. First introduced as a preview in JDK 25, this PEM API’s second iteration brings several updates. For instance, the PEMRecord class has been renamed to PEM and now incorporates a decode()method to retrieve decoded Base64 content. Additionally, the encryptKey methods within the EncryptedPrivateKeyInfo class are now simply encrypt and can accept DEREncodable objects instead of PrivateKey objects, thereby allowing for the encryption of KeyPair and PKCS8EncodedKeySpec objects.
The structured concurrency API streamlines concurrent programming by consolidating related tasks, distributed across various threads, into coherent units of work. This approach simplifies error management, cancellation processes, boosts overall reliability, and enhances code observability. The key aims are to foster a concurrent programming paradigm that mitigates typical risks associated with cancellation and shutdown, such as thread leaks and delays, while also improving the observability of concurrent code.
Developers will receive new warnings regarding the use of deep reflection to alter final fields. These warnings serve as preparation for a future release that will enforce integrity by default by preventing final field mutation, thereby making final truly final. This change aims to make Java applications more secure and potentially faster. To bypass these current warnings and future limitations, application developers can opt to selectively allow final field mutation only where absolutely necessary.
The G1 GC proposal seeks to boost application throughput when the G1 garbage collector is in use, by minimizing the synchronization needed between application and GC threads. Its objectives are to decrease G1’s synchronization overhead, lessen the footprint of injected code for G1’s write barriers, and preserve G1’s core architecture without altering user interaction.
The G1 GC proposal notes that although G1, which is the default garbage collector of the HotSpot JVM, is designed to balance latency and throughput, achieving this balance sometimes impacts application performance adversely compared to throughput-oriented garbage collectors such as the Parallel and Serial collectors:
Compared to the Parallel collector, G1 executes a greater portion of its operations simultaneously with the application, thereby shortening garbage collection pauses and enhancing latency. Inevitably, this necessitates that application threads share CPU resources and coordinate with GC threads, a synchronization process that can diminish throughput and elevate latency.
The HTTP/3 proposal aims to enable Java libraries and applications to communicate with HTTP/3 servers with minimal modification to existing code. Key objectives include enhancing the HTTP Client API to facilitate sending and receiving HTTP/3 requests and responses, ensuring that only minor adjustments are needed for the HTTP Client API and Java application code, and providing developers with the option to explicitly enable HTTP/3 instead of making it the default protocol in place of HTTP/2.
HTTP/3 stands as a significant iteration of the web’s primary data communication protocol, HTTP (Hypertext Transfer Protocol). This third version is founded upon the IETF QUIC (Quick UDP Internet Connections) transport protocol, which is characterized by its flow-controlled streams, rapid connection setup, ability to migrate network paths, and robust security features, among other advancements.
JDK 26 is also slated to remove the Java Applet API, which is now deemed obsolete. The Applet API had already been marked for deprecation and removal in JDK 17 back in 2021. As per the proposal, its obsolescence stems from the fact that neither modern JDK versions nor contemporary web browsers continue to support applets. The proposal concludes that retaining this unused and non-functional API is unwarranted.
