Java Development Kit (JDK) 25, a planned long-term support (LTS) release of standard Java, has reached the second rampdown or bug-fixing phase, as of July 17. This latest version of Java has 18 features.

JDK 25 comes on the heels ofJDK 24, a six-month-support release that arrived March 18. As a long-term support release, JDK 25 will get at least five years ofPremier support from Oracle. JDK 25 is due to arrive as a production release on September 16, following two release candidates planned for August 17 and August 21.

The most recent LTS release wasJDK 21, which arrived in September 2023.

Early access builds of JDK 25 can be downloaded fromjdk.java.net. The features slated for JDK 25 include an enhancement to the JDK Flight Recorder (JFR) to capture CPU-time profiling information on Linux, PEM (Privacy-Enhanced Mail) encodings of cryptographic objects, the Shenandoah garbage collector, 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, and a third preview of primitive types in patterns, instanceof, and switch. Other features include 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, a stable values API, and removal of the 32-bit x86 port.

JFR CPU-time profiling enhances the JDK Flight Recorder to capture CPU-time profiling information on Linux. The JFR is the JDK’s profiling and monitoring facility. Enhancing the JFR to use the Linux kernel’s CPU timer to safely produce CPU-time profiles of Java programs would help developers optimize the efficiency of the Java applications they deploy on Linux. CPU-time profiling on the JFR may be added for other platforms in the future. The CPU time-profiling feature is the third feature involving the JFR in JDK 25, with the others being the cooperative sampling and method timing and tracing capabilities. This is an experimental feature.

WithPEM encodings of cryptographic objects, JDK 25 previews a concise API for encoding objects that represent cryptographic keys, certificates, and certificate revocation into the widely usedPEM 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 formatsPKCS#8 (for private keys),X.509 (for public keys, certificates, and certificate revocation lists), andPKCS#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 wasplanned 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 byahead-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. TheAOT 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, thejcmd tool, and over the network via theJava Management Extensions API. Timing and tracing method invocations can help identify performance bottlenecks, optimize code, and find the root cause 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 ofprimitive types in patterns, instanceof, and switch would enhance pattern matching by allowing primitive types in all pattern contexts and extendinstanceof andswitch to work with all primitive types. Originally proposed inJDK 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 inJDK 20, proposed for preview inJDK 21, and subsequently refined forJDK 22 throughJDK 24. The feature will be finalized in JDK 25, with one change: theScopedValue.orElse method no longer acceptsnull as its argument.

Thevector 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 toJDK 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 theForeign Function and Memory API rather than customC++ code inside the HotSpot JVM, thus improving maintainability. Second, addition, subtraction, division, multiplication, square root, and fused multiply/add operations onFloat16 values now are auto-vectorized on supporting x64 CPUs. Additionally,VectorShufflenow supports access to and fromMemorySegment.

Thekey 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 theHMAC-based Extract-and-Expand Key Derivation Function andArgon2. 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 asML-KEM, in higher level protocols such asHybrid 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 inJDK 21 throughJDK 24, after being incubated inJDK 19 andJDK 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, aStructuredTaskScope is now opened via static factory methods rather than public constructors. Also, the zero-parameteropen factory method covers the common case by creating aStructuredTaskScope that waits for all subtasks to succeed or any subtask to fail.

Flexible constructor bodies was previewed inJDK 22 as “statements before super(…)” as well as inJDK 23 andJDK 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 assuper (…) orthis (…).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 finalfields, 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 theforeign 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 theofficial feature list, JDK 25 also brings performance improvements to the classString, by allowing theString::hashCode function to take advantage of a compiler optimization called constant folding. Developers who use strings as keys in a static unmodifiableMap should see significant performance boosts, according to a May 1 article on Oracle’sInside Java website.