The most relevant new features in JDK 24

Since 2018, we’ve had a new release of the Java platform every six months. With Swiss watch-like regularity, the latest version of Java, JDK 24, is upon us. In an almost poetic way, JDK 24 contains 24 JDK Enhancement Proposals (JEPs), the largest number of new features since the introduction of the time-based release schedule.

I won’t go through each of them, as 10 are preview features, incubator modules, or experimental. Let’s look at the ones that will be most interesting to developers and those deploying Java.

Linking ahead of time

Part of the wider Project Leyden is JEP 483, Ahead-of-Time Class Loading and Linking. The goal of Project Leyden is to reduce the startup time associated with Java applications. One of Java’s greatest benefits is the use of the JVM, a virtual machine that enables an application to run on any platform without recompilation. This write once, run anywhere approach also delivers excellent scalability and performance using just-in-time (JIT) compilation. Unfortunately, this does not come without a cost, manifested as slower performance as the application warms up.  

There are several parts to Project Leyden, and JEP 483 is the first part to be delivered in the JDK. Ahead-of-Time Class Loading and Linking is related to Application Class Data Sharing, introduced in JDK 11, by making the classes of an application instantly available in a loaded and linked state when the JVM starts. This avoids the overhead of repeatedly loading, verifying, and linking class files every time an application starts.

JEP 485, Stream Gatherers, is a small but valuable change that will benefit developers. JDK 8 introduced the Stream API, which, combined with lambda expressions, provided a more functional programming style in Java.  

A stream consists of three parts: a source, zero or more intermediate operations, and a terminal operation. Developers have complete flexibility over what the terminal operation does by being able to specify arbitrary functionality implementing the Collector interface.  

For intermediate operations, there has been a fixed (albeit rich) set of methods available. In the same way that the Collector interface can be implemented for custom terminal operations, the Gatherer interface can now be implemented to provide custom intermediate operations.

So long, security manager

JEPs define enhancements to the JDK, but that doesn’t always mean adding something.  

In the case of JEP 486, Permanently Disable the Security Manager, this is removing functionality. At first sight, this particular JEP sounds a bit troubling. Remove the security manager? Isn’t that going to make the JDK less secure? The reality is quite different.  

The security manager has been part of Java since its first release and was included for use when executing remotely loaded code. By default, all remote code is treated as untrusted, so it is unable to access resources such as the file system, network and so on. Explicit permission must be granted for each required resource and form of access.  

The rationale for the security manager’s removal is that it has not been the primary means of securing client-side Java for a long time and is rarely used for securing server-side code. Long gone are the days of Applets, the browser plugin being removed in JDK 11. Given the security manager’s maintenance cost, it was deprecated in JDK 17 and is now no longer possible to use in JDK 24. 

Unfortunately, some developers have used this feature, but no alternative has been provided. Migrating these applications to JDK 24 and later will potentially require major architectural changes and recoding. Although Java has excellent backwards compatibility, applications occasionally must be changed to work on newer versions.

Virtual threads unpinned

Virtual threads were introduced in JDK 21 to enable much greater scalability of applications that typically used the thread-per-request programming model and where those threads spent significant time being blocked. However, virtual threads experienced limitations when using synchronized methods or blocks. Even if a virtual thread were blocked, if it was in a synchronized block or method, the underlying platform thread would not be released for use by other virtual threads. This resulted from the monitor used by the synchronized method or block being associated with the platform thread rather than the virtual thread.

JEP 491, Synchronize Virtual Threads without Pinning, resolves this limitation by moving the monitor association to the virtual thread. The JVM’s implementation of the synchronized keyword has been changed so that virtual threads can acquire, hold, and release monitors independently of their carriers. The mounting and unmounting operations now handle the bookkeeping necessary to allow a virtual thread to unmount and re-mount when inside a synchronized method or statement or when waiting on a monitor.

Unsafe and unnecessary

Since JDK 9, the encapsulation of the internal JDK APIs has increasingly tightened. In JDK 24, we take another step towards removing access completely.  

The infamous sun.misc.Unsafe class has always been an issue, as it contains functionality impossible to replicate through a user-written class. All memory-related methods are now available through public APIs provided by the VarHandle API and the Foreign Function & Memory API. JEP 498, Warn upon Use of Memory-Access Methods in sun.misc.Unsafe, means that the JVM will now Issue a warning at run time on the first occasion that any memory-access method in sun.misc.Unsafe is invoked.

The final JEP of interest is JEP 501, Deprecate the 32-bit x86 Port for Removal. In reality, this only affects the Linux version of this port, as the Windows one was removed in JDK 21 (JEP 449). Very few people still run applications on 32-bit operating systems, and it makes no sense to migrate them to a modern JDK without upgrading the OS to a 64-bit version simultaneously.

JDK 24 continues moving the Java platform forward, delivering the features developers and users will find helpful. Expect more of the same in JDK 25 (the next long-term support release) and beyond.

Simon Ritter is deputy CTO and Java champion at Azul.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.