Release of Java SE 24 and OpenJDK 24

After six months of development, Oracle has released the Java SE 24 platform (Java Platform, Standard Edition 24), which is benchmarked against the open project OpenJDK. Except for the removal of some obsolete features in Java SE 24, backward compatibility with previous versions of the Java platform has been maintained — most older Java projects will run without changes on the new version. Installable builds of Java SE 24 (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 24, developed within the OpenJDK project, is fully open under the GPLv2 license with GNU ClassPath exceptions allowing dynamic linking with commercial products.

Java SE 24 is classified as a regular support release, with updates being released until the next version comes out. The long-term support (LTS) branches to use are Java SE 21 or Java SE 17, with updates available until 2031 and 2029, respectively (publicly available until 2028 and 2026). Extended support for the LTS branch of Java SE 8 will continue until 2030, and Java SE 11 will last until 2032. The next LTS release will be the fall release of Java SE 25.

Among the innovations proposed in Java SE 24:

• An experimental generational mode of the Shenandoah garbage collector has been proposed, where old and newly created objects are processed separately to improve the efficiency of cleaning up short-lived objects. The 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 more work in parallel with the execution of Java applications.
• Experimental support for compact object headers has been implemented in the HotSpot JVM, with sizes reduced from 96 to 64 bits (from 12 to 8 bytes) on 64-bit systems. The reduction in header size helps shrink the heap and improve cache efficiency.
• The G1 garbage collector has simplified the implementation of barriers that monitor the application's access to memory. In the new version, the operations for extending barriers have been moved to a later stage of compilation in the C2 JIT. Tests conducted show that this transfer allows for a reduction in overhead in the C2 JIT compiler by 10-20%, depending on the application.
• An API has been added for using cryptographic key derivation functions (KDF) that allow for the generation of additional keys of required length based on a secret key (for example, a password) and an arbitrary set of data. The KDF API is currently in preview status.
• The ability for Ahead-of-Time (AOT) loading and linking of classes has been added. This change accelerates the startup of HotSpot JVM by providing the classes used in the application in an already loaded and linked state. During the initial startup of the application, the state of all classes is cached and used for speeding up loading in subsequent runs.
• A Class-File API has been added for parsing, generating, and transforming Java class files.

  ClassFile cf = ClassFile.of(); ClassModel classModel = cf.parse(bytes); byte[] newBytes = cf.build(classModel.thisClass().asSymbol(), classBuilder -> { for (ClassElement ce : classModel) { if (!(ce instanceof MethodModel mm && mm.methodName().stringValue().startsWith("debug"))) { classBuilder.with(ce); } } });

• An extended Stream API has been added, supporting the definition of custom intermediate operations that can be useful in cases where existing built-in intermediate operations are insufficient for the desired data transformation. Custom handlers are connected using the new intermediate operation Stream::gather(Gatherer), which processes stream elements applying a user-defined handler. jshell > Stream.of(1,2,3,4,5,6,7,8,9).gather(new WindowFixed(3)).toList() $1 ==> [[1, 2, 3], [4, 5, 6], [7, 8, 9]]
• The fourth preview implementation of Scoped Values has been proposed, allowing the shared use of immutable data across threads and efficient data exchange between child threads (values are inherited). Scoped Values are being developed to replace thread-local variables and are more efficient when using a very large number of virtual threads (thousands and millions of threads). The main difference between Scoped Values and thread-local variables is that the former is written once, cannot be changed afterward, and remains accessible only during the thread's execution.
• The pattern matching mechanism has been enhanced with preliminary support for the use of primitive types (int, byte, char, and other basic non-object types) in all template forms, in the 'instanceof' operator, and in 'switch' blocks. switch (x.getStatus()) { case 0 -> "okay"; case 1 -> "warning"; case 2 -> "error"; case int i -> "unknown status: " + i; } if (i instanceof byte b) { … b … }
• A ninth preview implementation of the Vector API has been proposed, providing functions for vector computations that are executed using 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 in the HotSpot JIT compiler, the new API allows for explicit control over vectorization for parallel data processing.
• Support for synchronizing virtual threads without pinning them to platform-related threads has been implemented. Virtual threads in a synchronized method or expression in a blocking state now release their platform thread, allowing other virtual threads to use it, significantly increasing the number of available virtual threads and improving the scalability of applications using multithreading.
• A third preliminary option has been added, allowing expressions to be specified in constructors before calling super(...), which is used to explicitly call the parent class constructor from the child class constructor when these expressions do not reference the instance being created by the constructor. class Outer { void hello() { System.out.println("Hello"); } class Inner { Inner() { hello(); super(); } } }
• The jlink utility now supports creating run-time images without using JMOD files, which can reduce the JDK size by approximately 25%.
• A second preliminary option has been added for using the expression "import module M" to import all packages exported by the specified module at once. This change significantly simplifies the reuse of module libraries, allowing libraries and classes to be included without specifying their location in the package hierarchy. For instance, specifying "import module java.base" will import all 54 packages included in the java.base module, which would previously have needed to be mentioned separately ("import java.io.*", "import java.util.*", etc.).
• A fourth preliminary implementation of implicitly declared classes and unnamed instances of the main method has been added, in which it is possible to do without public/static declarations, passing an array of arguments, and other entities related to class declaration. // previously public class HelloWorld { public static void main(String[] args) { System.out.println("Hello world!"); } } // now it can be void main() { System.out.println("Hello, World!"); }
• A fourth preliminary version of the API for structured concurrency has been proposed for testing, simplifying the development of multithreaded applications by treating multiple tasks running in different threads as a single block.
• The KeyPairGenerator, Signature, and KeyFactory APIs have been enhanced to support the algorithms ML-KEM (CRYSTALS-Kyber) and ML-DSA (CRYSTALS-Dilithium), standardized by the National Institute of Standards and Technology (NIST) and resistant to attacks on quantum computers. These algorithms employ cryptographic methods based on solving lattice theory problems, the solution time of which does not differ between classical and quantum computers.
• Support for the non-generational mode that does not separate the handling of 'old' and 'young' objects has been removed from the ZGC garbage collector. Starting with Java SE 23, the generational mode of ZGC is applied by default.
• Warnings regarding the use of the JNI (Java Native Interface) and FFM (Foreign Function & Memory) APIs have been added to prepare developers for the limitations on access to these APIs due to the inclusion of integrity mode in a future release, which will by default prohibit interaction with native code.
• A warning is now issued when using external memory access methods (outside the JVM) provided by the class sun.misc.Unsafe. It is recommended to use the VarHandle API for accessing off-heap memory and interacting with external code. Support for sun.misc.Unsafe was deprecated in the previous release.
• The Security Manager has been removed, as it has long been outdated and unnecessary since the discontinuation of support for the browser plugin. The Security Manager was marked as deprecated in Java 17. A complete removal of the Security Manager code is planned for one of the upcoming releases.
• Code to support the 32-bit version of the Windows OS on x86 systems has been removed. The Java port for 32-bit x86 systems has been declared deprecated and is scheduled for removal (support for 32-bit Linux on x86 systems will also be discontinued).

Additionally, the release of an upgrade to the platform for creating applications with JavaFX 24 and a new release of the universal virtual machine GraalVM is noteworthy, supporting the execution of applications in JavaScript (Node.js), Python, Ruby, R, any languages for the JVM (Java, Scala, Clojure, Kotlin), and languages for which LLVM bitcode can be generated (C, C++, Rust). Besides support for JDK 24, the new version of GraalVM includes optimizations for machine learning tasks, improved support for compiling Java bytecode into machine code, and the addition of the SkipFlow mechanism to reduce executable file sizes and compilation times.

Source: opennet.ru