{"id":143670,"date":"2025-09-17T11:12:01","date_gmt":"2025-09-17T09:12:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-25-lts-i-openjdk-25"},"modified":"2025-09-17T11:12:01","modified_gmt":"2025-09-17T09:12:01","slug":"vypusk-java-se-25-lts-i-openjdk-25","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/vypusk-java-se-25-lts-i-openjdk-25","title":{"rendered":"The release of Java SE 25 LTS and OpenJDK 25","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
After six months of development, Oracle has released the Java SE 25 platform (Java Platform, Standard Edition 24), with the OpenJDK open-source project serving as its reference implementation. With the exception of the removal of some deprecated features, Java SE 25 maintains backward compatibility with previous versions of the Java platform\u2014most previously written Java projects will run without modifications on the new version. Installable builds of Java SE 25 (JDK, JRE, and Server JRE) are prepared for Linux (x86_64, AArch64), Windows (x86_64), and macOS (x86_64, AArch64). The reference implementation of Java SE 25 developed under the OpenJDK project is fully open under the GPLv2 license with GNU ClassPath exceptions, allowing dynamic linking with commercial products. <\/p>\n
Java SE 25 is classified as a release with an extended support period, with updates scheduled until 2033 (public updates will continue until September 2030). The long-term support (LTS) branches of Java SE 17 and 21 also continue to receive support, with updates issued until 2029 and 2031, respectively (public updates\u2014until 2026 and 2028). Extended support for the LTS branches of Java SE 8 and 11 will last until 2030 and 2032. <\/p>\n
Among the innovations introduced in Java SE 25 (1, 2, 3, 4): <\/p>\n
\n
An experimental StableValue API has been added for working with objects containing immutable data that are treated as constants in the JVM. Performance optimizations similar to fields marked with the 'final' keyword are applied to such objects. The StableValue API separates the creation of constant values from their initialization, ensures that a value can be initialized only once, reduces program startup time, and enables constant-folding optimizations in user code that were previously used only in the internal JDK code. class Application { \/\/ Previously: \/\/ static final UserService USERS = new UserService(); \/\/ Now: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }\n
An experimental API has been added for encoding and decoding objects with cryptographic keys, certificates, and certificate revocation lists, using the PEM (Privacy-Enhanced Mail) format.\n
Support for Scoped Values has been added, allowing immutable data to be shared across threads and enabling efficient data exchange between child threads (values are inherited). Scoped Values are evolving to replace the mechanism of thread-local variables and are more efficient when using a very large number of virtual threads (thousands or millions of threads). The main difference between Scoped Values and thread-local variables is that the former are written once, cannot be changed afterward, and remain available only during the thread's execution.\n
An API has been added for using key derivation functions (KDF), which allow the generation of additional keys of the required length based on a secret key (e.g., a password) and an arbitrary set of data.\n
Code and build scripts for supporting 32-bit x86 systems have been removed. The discontinuation of support for 32-bit x86 systems has simplified the infrastructure for building and testing the JDK, and it has enabled the implementation of platform-dependent features without creating fallback handlers for 32-bit x86 systems.\n
A new capability has been added to use a single expression \u2018import module M\u2019 to import all packages exported by the specified module at once. This change significantly simplifies the reuse of modular libraries, allowing libraries and classes to be included without specifying their location in the package hierarchy. For example, stating \u2018import module java.base\u2019 will import all 54 packages contained in the java.base module, which would have previously needed to be mentioned separately (\u2018import java.io.*\u2019, \u2018import java.util.*\u2019, etc.).\n
A compact format for programs has been proposed, which can be useful for learning and developing small applications. In the compact form, defining unnecessary classes is not required; typical APIs are automatically imported, and simplified input\/output methods are available. For instance, the \u2018Hello, World!\u2019 application can be reduced to: void main() { IO.println(\u2018Hello, World!\u2019); }\n
Allowing expressions to be specified in constructors before calling super(\u2026), which is used to explicitly call the constructor of the parent class from the constructor of the inherited class, is now permitted if these expressions do not refer to the instance being created by the constructor. class Outer { void hello() { System.out.println(\u2018Hello\u2019); } class Inner { Inner() { hello(); super(); } } }\n
A generational mode has been added to the Shenandoah garbage collector, where old and recently created objects are processed separately to enhance the efficiency of cleaning up objects with short lifetimes. This new mode provides more predictable throughput, resilience to changing loads, and reduced memory consumption during garbage collection. The Shenandoah scheduler aims to reduce pause times during garbage collection by performing a larger volume of work in parallel with the execution of Java applications.\n
The creation of a cache for Ahead-of-Time loading and linking of classes has been simplified, allowing for faster startup of the HotSpot JVM by utilizing classes in an already loaded and linked state. Separate operations for recording activity and creating a cache are no longer required at startup; one command is sufficient: java -XX:AOTCacheOutput=app.aot -cp app.jar com.example.App \u2026\n
On startup, the HotSpot Java VM has implemented the ability to use method execution profiles obtained during the previous application run. This change allows the JIT compiler to operate without accumulating statistics and to begin generating native code immediately without waiting for the profile to be formed.\n
The HotSpot JVM has implemented support for compact object headers, the size of which has been reduced from 96 to 64 bits (from 12 to 8 bytes) on 64-bit systems. The reduction in header size allows for a decrease in heap size and improves cache efficiency.\n
The proposed test implementation of the Vector API provides functions for vector computations that utilize the vector instructions of x86_64 and AArch64 processors, allowing operations to be applied simultaneously to multiple values (SIMD). Unlike the auto-vectorization capabilities of scalar operations provided by the HotSpot JIT compiler, the new API enables explicit control over vectorization for parallel data processing.\n
A fifth preliminary version of the API for Structured Concurrency has been proposed for testing, simplifying the development of multithreaded applications by handling multiple tasks executed in different threads as a single block.\n
In the pattern matching mechanism, a third preliminary option for using primitive types (int, byte, char, and other basic types that are not objects) has been proposed in all types of patterns, in the \u2018instanceof\u2019 operator, and in \u2018switch\u2019 blocks. switch (x.getStatus()) { case 0 -> \u2018okay\u2019; case 1 -> \u2018warning\u2019; case 2 -> \u2018error\u2019; case int i -> \u2018unknown status: \u2019 + i; } if (i instanceof byte b) { \u2026 b \u2026 }\n
JDK Flight Recorder (JFR) has added experimental support for profiling with more accurate tracking of CPU resource consumption on the Linux platform. The runtime information of various constructs can be visually represented using colorful FlameGraphs.\n
The stability of JDK Flight Recorder (JFR) has been improved during asynchronous sampling of Java thread stacks by bypassing the call stack only at 'safepoint' locations.\n
JDK Flight Recorder (JFR) now includes tools for tracing and measuring the execution time of methods. It supports call stack tracing of specific methods and the recording of precise statistics about method calls, covering metrics such as execution time and call counts. <\/ul>\n