JDK 24: The New Features in Java 24

Transcript

Features optimizing JVM performance, startup time, or resource consumption JEP 404 introduces a generational mode to Shenandoah garbage collector. It will be able to maintain young and old generations and collect young objects more frequently. As a result, it will preserve low pause times, but use less memory and will be more performant generally.

JEP 450 marks the introduction of project Lilliput to the mainline OpenJDK. This project is aimed at reducing the Java object headers from 128 bits to 64 bits on 64-bit architectures.

JEP 475: Late Barrier Expansion for G1 It will reduce the size of the live data, potentially reducing the CPU and memory footprint of Java applications JEP 475 introduces the late barrier expansion for the G1 garbage collector.

JEP 483: Ahead-of-Time Class Loading & Linking This feature will help to improve the performance of Java applications in the cloud, as it will help to reduce the CPU time and memory overhead during the JVM warmup. JEP 483 marks the initial introduction of project Leyden to the mainline OpenJDK. This particular feature creates an AOT cache that stores class data after reading, parsing, loading, and linking classes.

JEP 489: Vector API (Ninth Incubator) This way, JVM will have less work to do during the startup. Preliminary tests show that AOT cache yields about 40% better startup time. JEP 489 introduces a ninth incubator of the Vector API, with a few important enhancements to the feature. This API will be incubated until the necessary features of Project Valhalla will be introduced to the OpenJDK mainline.

JEP 490: ZGC: Remove the Non-Generational Mode After that, vector API will be promoted to the preview feature. Z GC became generational in Java 21. Maintaining young and old generations helps the GC to collect young objects more frequently, thus reducing the GC overhead and heap memory overhead. JEP 49O removes the non-generational mode as it is no longer needed.

JEP 491 will allow the virtual threads to mount and unmount the platform thread in the ‘synchronized’ method without staying pinned to it. This will enable the developers to continue using the synchronized methods, and at the same time, it will eliminate the negative impact on scalability.

JEP 493 introduces a new feature that will enable the jlink tool to cut the size of the JDK by about 25% by excluding the JMOD files from the run-time JDK images.

JEP 485: Stream Gatherers This feature will not be enabled by default, and JDK vendors will decide whether to enable it. By the way, Liberica JDK Lite, which is the flavor of Liberica JDK optimized for the cloud, hasn't included the JMOD files all along. So you can use smaller Java base images right now! JEP 485 finalizes the Stream Gatherers.

JEP 487: Scoped Values (Fourth Preview) It is an addition to the Stream API that enables the developers to use custom intermediate operations with streams, thus reducing the boilerplate code. JEP 487 introduces a forth preview of the scoped values. Scoped values have a limited lifetime and share immutable data in one way, from the caller to the callees. J

EP 488: Primitive Types in Patterns, instanceof, and switch (Second Preview) These values are accessible only to the methods invoked directly or indirectly by the ‘run’ method. This enables more reliable data sharing in concurrent code. JEP 488 introduces a second preview of primitive types in patterns, instanceof, and switch. This feature enables more uniform data exploration and eliminates the risks of data loss due to unsafe casts.

JEP 492 introduces a third preview of flexible constructor bodies. This feature enables developers to place statements in a constructor before the explicit invocation of another constructor. As a result, it is possible to avoid writing additional methods or constructors to compute or validate some values necessary for the constructor of the superclass.

JEP 494 introduces a second preview of module import declarations. Thanks to this feature, developers can implicitly import all module packages by simply importing the module. It reduces the noise of multiple on-demand imports, and facilitates coding in Java for beginners. Two main changes: Allow for the import of the whole Java SE API When importing the Java module, Allow on-demand import declarations to shadow module import declarations.

JEP 495 introduces a fourth preview of simple source files and instance main methods with a few changes to the terminology and the title. This feature enables the developers, who have just started their Java journey, to write single-class simple programs without complicated Java concepts.

JEP 499 introduces a fourth preview of structured concurrency. Features enhancing the security of Java apps

JEP 478: Key Derivation Function API (Preview) JEP 478 introduces a preview of the Key Derivation Function API. Prior to JDK 24, Java didn't have a specific API for using the Key Derivation Functions (KDFs). Now, the developers will be able to use more sophisticated password-hashing functions. This is a step towards introducing the Post-Quantum Cryptography algorithms to the Java Platform. JEP 496 introduces the implementation of the quantum resistant Module-Lattice-Based Key-Encapsulation Mechanism ML-KEM has been standardized by the United States National Institute of Standards and Technology. The implementation of this mechanism in the Java platform will facilitate the upgrade of the Java applications to use ML-KEM.

JEP 497 introduces the implementation quantum-resistant Module-Lattice-Based Digital Signature Algorithm. This algorithm has been also standardized by the NIST. ML-DSA is used for assigning and authenticating identities in the quantum-resistant fashion.

JEP 484 finalizes the Class-File API introduced in JDK 22. JEP 484: Class-File API Removals, deprecations, restrictions JEP 472: Prepare to Restrict the Use of JNI Frameworks and tools will rely on this standard JDK API, meaning that they will automatically use the latest class-file format So, developers can update the JDK version in their project without risking in most cases that the changes will be incompatible with the current framework or tooling versions. JEP 472 makes the JVM issue warnings on the usage of the Java Native Interface and Foreign Function & Memory API.

JEP 479: Remove the Windows 32-bit x86 Port This feature lays ground for further restriction of native access to ensure Java's integrity by default. Developers can explicitly enable native access at application startup to avoid warnings and exceptions in the future. The windows 32-bit x86 port was deprecated in JDK 21. JEP 479 removes this port completely, so the OpenJDK community will be able to concentrate on more relevant features. JEP 486 permanently disables the Security Manager API, which has been around since the first Java version. It was rarely implemented due to the complexity of its use, but library developers had to dedicate time and resources to maintain compatibility with the feature, so it was decided to remove it. JEP 498 will make the JVM issue warnings if the memory-access methods in the sun.misc.Unsafe package are used.

JEP 501: Deprecate the 32-bit x86 Port for Removal This is done to prepare the platform for the removal of memory-access methods in this package in the future. Developers should use a more reliable and secure APIs, such as Variable Handles and Foreign Function & Memory API. JEP 501 deprecates the 32-bit Linux x86 port, which is the only 32 bit x86 port remaining in the OpenJDK. No new hardware is released specifically for this architecture, and porting new Java features to this port requires a lot of work, so it will be more beneficial to stop maintaining this port and focus on more relevant JDK features.