Key: JDK-X - https://bugs.openjdk.java.net/browse/JDK-X CVE-XXXX-YYYY: https://cve.mitre.org/cgi-bin/cvename.cgi?name=XXXX-YYYY New in release OpenJDK 24.0.0 (2025-03-18): =========================================== Major changes are listed below. Some changes may have been backported to earlier releases following their first appearance in OpenJDK 22 through to 25. NEW FEATURES ============ Language Features ================= Flexible Constructor Bodies ============================ https://openjdk.org/jeps/447 https://openjdk.org/jeps/482 https://openjdk.org/jeps/492 In constructors in the Java programming language, allow statements to appear before an explicit constructor invocation, i.e., super(..) or this(..). The statements cannot reference the instance under construction, but they can initialize its fields. Initializing fields before invoking another constructor makes a class more reliable when methods are overridden. This was introduced as a preview language feature (http://openjdk.java.net/jeps/12) in OpenJDK 22 (JEP 447) under the name "Statements before super(...)". It reached a second preview in OpenJDK 23 (JEP 482) with the addition of allowing fields to be initialized before invoking another constructor. It reaches a third preview in OpenJDK 24 (JEP 492). Unnamed Patterns and Variables ============================== https://openjdk.org/jeps/443 https://openjdk.org/jeps/456 Enhance the Java language with unnamed patterns, which match a record component without stating the component's name or type, and unnamed variables, which can be initialized but not used. Both are denoted by an underscore character, _. This feature is now final. It was a preview feature (http://openjdk.java.net/jeps/12) in OpenJDK 21 (JEP 443). Primitive Types in Patterns, instanceof, and switch =================================================== https://openjdk.org/jeps/455 https://openjdk.org/jeps/488 Enhance pattern matching by allowing primitive type patterns in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is a preview language feature (http://openjdk.java.net/jeps/12) introduced in OpenJDK 23 (JEP 455) and having its second preview in OpenJDK 24 (JEP 488). Module Import Declarations ========================== https://openjdk.org/jeps/476 https://openjdk.org/jeps/494 Enhance the Java programming 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. This is a preview language feature (http://openjdk.java.net/jeps/12) introduced in OpenJDK 23 (JEP 476) and reaching a second preview in OpenJDK 24 (JEP 494). Library Features ================ Foreign Function & Memory API ============================= https://openjdk.org/jeps/412 https://openjdk.org/jeps/419 https://openjdk.org/jeps/424 https://openjdk.org/jeps/434 https://openjdk.org/jeps/442 https://openjdk.org/jeps/454 Introduce an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI. This API is now finalised. It was first introduced in incubation (https://openjdk.java.net/jeps/11) in OpenJDK 17 (JEP 412), and is an evolution of the Foreign Memory Access API (OpenJDK 14 through 16) and Foreign Linker API (OpenJDK 16) (see release notes for java-17-openjdk). OpenJDK 18 saw a second round of incubation (JEP 419) before its inclusion as a preview feature (http://openjdk.java.net/jeps/12) in OpenJDK 19 (JEP 424). A second preview took place in OpenJDK 20 (JEP 434) and a third and final preview in OpenJDK 21 (JEP 442). Prepare to Restrict the Use of JNI ================================== https://openjdk.org/jeps/472 Issue warnings about uses of the Java Native Interface (JNI) and adjust the Foreign Function & Memory (FFM) API to issue warnings in a consistent manner. All such warnings aim to prepare developers for a future release that ensures integrity by default by uniformly restricting JNI and the FFM API. Application developers can avoid both current warnings and future restrictions by selectively enabling these interfaces where essential using the --enable-native-access command-line option. Class-File API ============== https://openjdk.org/jeps/457 https://openjdk.org/jeps/466 https://openjdk.org/jeps/484 Provide a standard API for parsing, generating, and transforming Java class files. This API is now finalised. It was introduced as a preview library feature (http://openjdk.java.net/jeps/12) in OpenJDK 22 (JEP 457) with a second preview in OpenJDK 23 (JEP 466). Vector API ========== https://openjdk.org/jeps/338 https://openjdk.org/jeps/414 https://openjdk.org/jeps/417 https://openjdk.org/jeps/426 https://openjdk.org/jeps/438 https://openjdk.org/jeps/448 https://openjdk.org/jeps/460 https://openjdk.org/jeps/469 https://openjdk.org/jeps/489 Introduce an API to express vector computations that reliably compile at runtime to optimal vector hardware instructions on supported CPU architectures and thus achieve superior performance to equivalent scalar computations. This is an incubation feature (https://openjdk.java.net/jeps/11) introduced in OpenJDK 16 (JEP 338). A second round of incubation took place in OpenJDK 17 (JEP 414), OpenJDK 18 (JEP 417) saw a third, OpenJDK 19 a fourth (JEP 426), OpenJDK 20 (JEP 438) a fifth, OpenJDK 21 a sixth (JEP 448), OpenJDK 22 a seventh (JEP 460), OpenJDK 23 an eighth (JEP 469) and it reaches its ninth in OpenJDK 24 (JEP 489). Stream Gatherers ================ https://openjdk.org/jeps/461 https://openjdk.org/jeps/473 https://openjdk.org/jeps/485 Enhance the Stream API to support custom intermediate operations. This will allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations. This API is now finalised. It was introduced as a preview library feature (http://openjdk.java.net/jeps/12) in OpenJDK 22 (JEP 461) with a second preview in OpenJDK 23 (JEP 473). Structured Concurrency ====================== https://openjdk.org/jeps/428 https://openjdk.org/jeps/437 https://openjdk.org/jeps/453 https://openjdk.org/jeps/462 https://openjdk.org/jeps/480 https://openjdk.org/jeps/499 Simplify multithreaded programming by introducing an API for structured concurrency. Structured concurrency treats multiple tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This API was first introduced in incubation (https://openjdk.java.net/jeps/11) in OpenJDK 19 (JEP 428) and had a second round of incubation in OpenJDK 20 (JEP 437). It became a preview feature (http://openjdk.java.net/jeps/12) in OpenJDK 21 (JEP 453), reached its second preview in OpenJDK 22 (JEP 462), had a third preview in OpenJDK 23 (JEP 480) and reaches its fourth in OpenJDK 24 (JEP 499). Simple Source Files and Instance Main Methods ============================================= https://openjdk.org/jeps/445 https://openjdk.org/jeps/463 https://openjdk.org/jeps/477 https://openjdk.org/jeps/495 Evolve the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. Experienced developers can likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large. This library feature was introduced as a preview (http://openjdk.java.net/jeps/12) in OpenJDK 21 (JEP 445) under the name "Unnamed Classes and Instance Main Methods". It reached a second preview in OpenJDK 22 (JEP 463) and a third in OpenJDK 23 (JEP 477) under the new name, "Implicitly Declared Classes and Instance Main Methods", due to the move away from unnamed classes to an implicitly declared name chosen by the host system. It has a fourth preview in OpenJDK 24 (JEP 495) with new terminology and a revised title, but otherwise unchanged. Scoped Values ============= https://openjdk.org/jeps/429 https://openjdk.org/jeps/446 https://openjdk.org/jeps/464 https://openjdk.org/jeps/481 https://openjdk.org/jeps/487 Introduce scoped values, which enable the sharing of immutable data within and across threads. They are preferred to thread-local variables, especially when using large numbers of virtual threads. This API was first introduced in incubation (https://openjdk.java.net/jeps/11) in OpenJDK 20 (JEP 429). It became a preview feature (http://openjdk.java.net/jeps/12) in OpenJDK 21 (JEP 446), had a second preview in OpenJDK 22 (JEP 464), a third in OpenJDK 23 (JEP 481) and reaches its fourth in OpenJDK 24 (JEP 487). Key Derivation Function API =========================== https://openjdk.org/jeps/478 Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. This is a preview library feature (http://openjdk.java.net/jeps/12) introduced in OpenJDK 24 (JEP 478). Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism ================================================================== https://openjdk.org/jeps/496 Enhance the security of Java applications by providing an implementation of the quantum-resistant Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM). Key encapsulation mechanisms (KEMs) are used to secure symmetric keys over insecure communication channels using public key cryptography. ML-KEM is designed to be secure against future quantum computing attacks. It has been standardized by the United States National Institute of Standards and Technology (NIST) in FIPS 203 [0]. [0] https://csrc.nist.gov/pubs/fips/203/final Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm ================================================================== https://openjdk.org/jeps/497 Enhance the security of Java applications by providing an implementation of the quantum-resistant Module-Lattice-Based Digital Signature Algorithm (ML-DSA). Digital signatures are used to detect unauthorized modifications to data and to authenticate the identity of signatories. ML-DSA is designed to be secure against future quantum computing attacks. It has been standardized by the United States National Institute of Standards and Technology (NIST) in FIPS 204 [0]. [0] https://csrc.nist.gov/pubs/fips/204/final Virtual Machine Enhancements ============================ Region Pinning for G1 ===================== https://openjdk.org/jeps/423 Reduce latency by implementing region pinning in G1, so that garbage collection need not be disabled during Java Native Interface (JNI) critical regions. ZGC: Generational Mode by Default ================================= https://openjdk.org/jeps/439 https://openjdk.org/jeps/474 Switch the default mode of the Z Garbage Collector (ZGC) to the generational mode. Deprecate the non-generational mode, with the intent to remove it in a future release. Late Barrier Expansion for G1 ============================= https://openjdk.org/jeps/475 Simplify the implementation of the G1 garbage collector's barriers, which record information about application memory accesses, by shifting their expansion from early in the C2 JIT's compilation pipeline to later. Ahead-of-Time Class Loading & Linking ===================================== https://openjdk.org/jeps/483 Improve startup time by making the classes of an application instantly available, in a loaded and linked state, when the HotSpot Java Virtual Machine starts. Achieve this by monitoring the application during one run and storing the loaded and linked forms of all classes in a cache for use in subsequent runs. Lay a foundation for future improvements to both startup and warmup time. Using this feature requires a three stage process: 1. Populate the Ahead-of-Time configuration data with a training run of the application using the options `-XX:AOTMode=record -XX:AOTConfiguration=` where `` is the configuration reference to use in #2. 2. Create the Ahead-of-Time cache using the options `-XX:AOTMode=create -XX:AOTConfiguration= -XX:AOTCache=` where `` is the configuration reference from #1 and `` is the cache reference to use in later runs. 3. When running the application in testing or production, use the option `-XX:AOTCache=` to run the application with the cache generated in #2. Synchronize Virtual Threads without Pinning =========================================== https://openjdk.org/jeps/491 Improve the scalability of Java code that uses synchronized methods and statements by arranging for virtual threads that block in such constructs to release their underlying platform threads for use by other virtual threads. This will eliminate nearly all cases of virtual threads being pinned to platform threads, which severely restricts the number of virtual threads available to handle an application's workload. Generational Shenandoah ======================= https://openjdk.org/jeps/404 Enhance the Shenandoah garbage collector with experimental generational collection capabilities to improve sustainable throughput, load-spike resilience, and memory utilization. This is an experimental feature that needs to be explicitly enabled with -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational Compact Object Headers ====================== https://openjdk.org/jeps/450 Reduce the size of object headers in the HotSpot JVM from between 96 and 128 bits down to 64 bits on 64-bit architectures. This will reduce heap size, improve deployment density, and increase data locality. This is an experimental feature that needs to be explicitly enabled with -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders Tools ===== Launch Multi-File Source-Code Programs ====================================== https://openjdk.org/jeps/458 Enhance the java application launcher to be able to run a program supplied as multiple files of Java source code. This will make the transition from small programs to larger ones more gradual, enabling developers to choose whether and when to go to the trouble of configuring a build tool. Markdown Documentation Comments =============================== https://openjdk.org/jeps/467 Enable JavaDoc documentation comments to be written in Markdown rather than solely in a mixture of HTML and JavaDoc @-tags. Linking Run-Time Images without JMODs ===================================== https://openjdk.org/jeps/493 Reduce the size of the JDK by approximately 25% by enabling the jlink tool to create custom run-time images without using the JDK's JMOD files. This feature must be enabled when the JDK is built using the --enable-linkable-runtime option. It will not be enabled by default, and some JDK vendors may choose not to enable it. DEPRECATIONS ============ Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal ================================================================== https://openjdk.org/jeps/471 Deprecate the memory-access methods in sun.misc.Unsafe for removal in a future release. These unsupported methods have been superseded by standard APIs, namely the VarHandle API (JEP 193, OpenJDK 9) and the Foreign Function & Memory API (JEP 454, OpenJDK 22). We strongly encourage library developers to migrate from sun.misc.Unsafe to supported replacements, so that applications can migrate smoothly to modern JDK releases. Warn upon Use of Memory-Access Methods in sun.misc.Unsafe ========================================================= https://openjdk.org/jeps/498 Issue a warning at run time on the first occasion that any memory-access method in sun.misc.Unsafe is invoked. All of these unsupported methods were terminally deprecated in JDK 23 (see JEP 471 above). They have been superseded by standard APIs, namely the VarHandle API (JEP 193, OpenJDK 9) and the Foreign Function & Memory API (JEP 454, OpenJDK 22). We strongly encourage library developers to migrate from sun.misc.Unsafe to supported replacements, so that applications can migrate smoothly to modern JDK releases. Permanently Disable the Security Manager ======================================== https://openjdk.org/jeps/486 The Security Manager has not been the primary means of securing client-side Java code for many years, it has rarely been used to secure server-side code, and it is costly to maintain. We therefore deprecated it for removal in OpenJDK 17 via JEP 411 (2021). As the next step toward removing the Security Manager, we will revise the Java Platform specification so that developers cannot enable it and other Platform classes do not refer to it. This change will have no impact on the vast majority of applications, libraries, and tools. We will remove the Security Manager API in a future release. Deprecate the 32-bit x86 Port for Removal ========================================= https://openjdk.org/jeps/501 Deprecate the 32-bit x86 port, with the intent to remove it in a future release. This will thereby deprecate the Linux 32-bit x86 port, which is the only 32-bit x86 port remaining in the JDK. It will also, effectively, deprecate any remaining downstream 32-bit x86 ports. After the 32-bit x86 port is removed, the architecture-agnostic Zero port will be the only way to run Java programs on 32-bit x86 processors. REMOVALS ======== String Templates ================ https://openjdk.org/jeps/430 https://openjdk.org/jeps/459 https://openjdk.org/jeps/465 This was a preview feature (http://openjdk.java.net/jeps/12) introduced in OpenJDK 21 (JEP 430) with a second preview in OpenJDK 22 (JEP 459). A third preview was proposed but ultimately withdrawn for OpenJDK 23 (JEP 465) and the feature is no longer present. See [0] for further explanation. [0] https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html Remove the Windows 32-bit x86 Port ================================== https://openjdk.org/jeps/449 https://openjdk.org/jeps/479 Remove the source code and build support for the Windows 32-bit x86 port. This port was deprecated for removal in JDK 21 by JEP 449 with the express intent to remove it in a future release. ZGC: Remove the Non-Generational Mode ===================================== https://openjdk.org/jeps/439 https://openjdk.org/jeps/474 https://openjdk.org/jeps/490 Remove the non-generational mode of the Z Garbage Collector (ZGC), keeping the generational mode as the default for ZGC (see JEP 439 & 474).