Long-term support release due in September has grown to 17 features including ahead-of-time command-line ergonomics and ahead-of-time method profiling.
Java Development Kit (JDK) 25, a planned long-term support release of standard Java due in September, has just added two more features, bringing the total number to 17. The latest additions include the generational Shenandoah garbage collector and a preview of PEM (Privacy-Enhanced Mail) encodings of cryptographic objects.
JDK 25 comes on the heels of JDK 24, a six-month-support release that arrived March 18. As a long-term support (LTS) release, JDK 25 will get at least five years of Premier support from Oracle. JDK 25 is due to arrive as a production release on September 16, following rampdown phases in June and July and two release candidates planned for August. The most recent LTS release was JDK 21, which arrived in September 2023.
Early access builds of JDK 25 can be downloaded from jdk.java.net. The features previously slated for JDK 25 include: ahead-of-time command-line ergonomics, ahead-of-time method profiling, JDK Flight Recorder (JFR) cooperative sampling, JFR method timing and tracing, compact object headers, a third preview of primitive types in patterns, instanceof, and switch. Also, scoped values, a vector API, a key derivation function API, structured concurrency, flexible constructor bodies, module import declarations, compact source files and instance main methods, stable values, and removal of the 32-bit x86 port.
With PEM encodings of cryptographic objects, JDK 25 previews a concise API for encoding objects that represent cryptographic keys, certificates, and certificate revocation into the widely used PEM format transport, and for decoding from the format back into objects. The Java platform has not had an easy-to-use API for decoding and encoding in the PEM format. A main goal of the feature is ease of use. Another goal is support for conversions between PEM text and cryptographic objects that have standard representations in the binary formats PKCS#8 (for private keys), X.509 (for public keys, certificates, and certificate revocation lists), and PKCS#8 v2.0 (for encrypted private keys and asymmetric keys).
Generational Shenandoah changes the generational mode of the Shenandoah garbage collector (GC) from an experimental feature to a product feature. Previewed in JDK 24, the GC has had many stability and performance enhancements, according to the proposal. The GC in JDK 24 was intended to offer collection capabilities to improve sustainable throughput, load-spike resilience, and memory utilization Several users have reported running demanding workloads with this GC. Generational Shenandoah once was planned for JDK 21 in 2023 but was dropped because the capability was deemed not ready at the time.
Ahead-of-time command-line ergonomics is intended to make it easier to create ahead-of-time (AOT) caches, which accelerate the startup of Java applications by simplifying commands needed for common use cases. Goals include simplifying the process of creating an AOT cache with no loss of expressiveness, and not introducing fundamentally new AOT workflows but making it easier to access existing ones. This proposal follows the ahead-of-time caches introduced by ahead-of-time class loading and linking in JDK 24.
Ahead-of-time method profiling would improve warmup time by making method execution profiles from a previous run of an application available right away when the HotSpot JVM starts. This will enable the just-in-time (JIT) compiler to generate native code instantly upon application startup rather than having to wait for the collection of profiles. Here, goals include helping applications warm up quicker; not requiring any changes to the code of applications, libraries, or frameworks; and not introducing any new constraints on application execution. The proposal also would not introduce new AOT workflows, but would use existing AOT cache creation commands. The AOT cache introduced in JDK 24 would be extended to collect method profiles during training runs.
JFR cooperative sampling would improve the stability of the JDK Flight Recorder when it asynchronously samples Java thread stacks. This would be achieved by walking call stacks only at safepoints while minimizing safepoint bias.
JFR method timing and tracing would extend the JDK Flight Recorder with facilities for method timing and tracing rather than via bytecode instrumentation. Goals of this feature include allowing execution times and stack traces to be recorded for specific methods without needing source code modifications, and recording exact statistics for method invocations. Another goal is allowing methods to be selected via command-line argument, configuration files, the jcmd tool, and over the network via the Java Management Extensions API. Timing and tracing method invocations can help identify performance bottlenecks, optimize code, and find the root causes of bugs.
Compact object headers, an experimental feature in JDK 24, would become a product feature in JDK 25. In JDK 24, this capability was introduced to reduce the size of object headers in the HotSpot JVM from between 96 bits and 128 bits down to 64 bits on 64-bit architectures. This reduces the heap size, improves deployment density, and increases data locality. Since JDK 24, compact object headers have proven their stability and performance, the proposal says.
A third preview of primitive types in patterns, instanceof, and switch would enhance pattern matching by allowing primitive types in all pattern contexts and extend instanceof and switch to work with all primitive types. Originally proposed in JDK 23 and followed up in JDK 24, this would still be a preview language feature in JDK 25. Among goals are enabling data exploration by allowing type patterns for all types, whether primitive or reference, and providing easy-to-use constructs that eliminate the risk of losing information due to unsafe casts.
Scoped values, to be previewed for a fifth time, allows a method to share immutable data with its callees within a thread and with child threads. Scoped values are easier to reason about than thread-local variables, according to the OpenJDK JDK Enhancement Proposal (JEP). They also have lower space and time costs, especially when used together with virtual threads and structured concurrency. Goals of the plan include ease of use, comprehensibility, robustness, and performance. The scoped values API was proposed for incubation in JDK 20, proposed for preview in JDK 21, and subsequently refined for JDK 22 through JDK 24. The feature will be finalized in JDK 25, with one change: the ScopedValue.orElse method no longer accepts null as its argument.
The vector API is designed to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPUs, thus achieving performance superior to equivalent scalar computations. The API will be incubated for the 10th time in JDK 25, after having been incubated in every release dating back to JDK 16. Two notable implementation changes are featured in the JDK 25 implementation of the API. First, the implementation now links to native mathematical-function libraries via the Foreign Function and Memory API rather than custom C++ code inside the HotSpot JVM, thus improving maintainability. Second, addition, subtraction, division, multiplication, square root, and fused multiply/add operations on Float16 values now are auto-vectorized on supporting x64 CPUs. Additionally, VectorShuffle now supports access to and from MemorySegment.
The key derivation function API provides for functions that are cryptographic algorithms for deriving additional keys from a secret key and other data. One of the goals of the API is enabling applications to use key derivation function algorithms such as the HMAC-based Extract-and-Expand Key Derivation Function and Argon2. Other goals include allowing security providers to implement key derivation function algorithms in either Java code or native code, and enabling the use of key derivation functions in key encapsulation mechanism implementations such as ML-KEM, in higher level protocols such as Hybrid Key Exchange in TLS 1.3, and in cryptographic schemes such as Hybrid Public Key Encryption. The API will be finalized in JDK 25 after being previewed in JDK 24.
Structured concurrency was previewed previously in JDK 21 through JDK 24, after being incubated in JDK 19 and JDK 20. Now in its fifth preview, structured concurrency treats groups of related tasks running in different threads as single units of work. This streamlines error handling and cancellation, improves reliability, and enhances observability, the proposal states. The primary goal is to promote a style of concurrent programming that can eliminate common risks arising from cancellation and shutdown, such as thread leaks and cancellation delays. A second goal is to improve the observability of concurrent code. JDK 25 introduces several API changes. In particular, a StructuredTaskScope is now opened via static factory methods rather than public constructors. Also, the zero-parameter open factory method covers the common case by creating a StructuredTaskScope that waits for all subtasks to succeed or any subtask to fail.
Flexible constructor bodies was previewed in JDK 22 as “statements before super(…)” as well as in JDK 23 and JDK 24. The feature is intended to be finalized in JDK 25. In flexible constructor bodies, the body of a constructor allows statements to appear before an explicit constructor invocation such as super (…) or this (…). These statements cannot reference the object under construction but they can initialize its fields and perform other safe computations. This change lets many constructors be expressed more naturally and allows fields to be initialized before becoming visible to other code in the class, such as methods called from a superclass constructor, thereby improving safety. Goals of the feature include removing unnecessary restrictions on code in constructors; providing additional guarantees that state of a new object is fully initialized before any code can use it; and reimagining the process of how constructors interact with each other to create a fully initialized object.
Module import declarations, which was previewed in JDK 23 and JDK 24, enhances the Java language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries but does not require the importing code to be in a module itself. Goals include simplifying the reuse of modular libraries by letting entire modules be imported at once; avoiding the noise of multiple type import-on-demand declarations when using diverse parts of the API exported by a module; allowing beginners to more easily use third-party libraries and fundamental Java classes without having to learn where they are located in a package hierarchy; and ensuring that module import declarations work smoothly alongside existing import declarations. Developers who use the module import feature should not be required to modularize their own code.
Compact source files and instance main methods evolves the Java language so beginners can write their first programs without needing to understand language features designed for large programs. Beginners can write streamlined declarations for single-class programs and seamlessly expand programs to use more advanced features as their skills grow. Likewise, experienced developers can write small programs succinctly without the need for constructs intended for programming in the large, the proposal states. This feature, due to be finalized in JDK 25, was previewed in JDK 21, JDK 22, JDK 23, and JDK 24, albeit under slightly different names. In JDK 24 it was called “simple source files and instance main methods.”
Stable values are objects that hold immutable data. Because stable values are treated as constants by the JVM, they enable the same performance optimizations that are enabled by declaring a field final. But compared to final fields, stable values offer greater flexibility regarding the timing of their initialization. A chief goal of this feature, which is in a preview stage, is improving the startup of Java applications by breaking up the monolithic initialization of application state. Other goals include enabling user code to safely enjoy constant-folding optimizations previously available only to JDK code; guaranteeing that stable values are initialized at most once, even in multi-threaded programs; and decoupling the creation of stable values from their initialization, without significant performance penalties.
Removal of the 32-bit x86 port involves removing both the source code and build support for this port, which was deprecated for removal in JDK 24. The cost of maintaining this port outweighs the benefits, the proposal states. Keeping parity with new features, such as the foreign function and memory API, is a major opportunity cost. Removing the 32-bit x86 port will allow OpenJDK developers to accelerate the development of new features and enhancements.
Separate from the official feature list, JDK 25 also brings performance improvements to the class String, by allowing the String::hashCode function to take advantage of a compiler optimization called constant folding. Developers who use strings as keys in a static unmodifiable Map should see significant performance boosts, according to a May 1 article on Oracle’s Inside Java web page.
