Oracle’s Mark Reinhold, Chief Architect of the Java Platform, has declared JDK 24 to be in Rampdown Phase Two, which means it is feature-frozen though late enhancements to existing JEPs (Java Enhancement Proposal) are possible subject to an “extraordinary high” bar.
JDK 24 is set for release on the March 18. It is not a long-term support (LTS) version; the next LTS version is JDK 25, expected on September 16.
Reinhold made the announcement on the OpenJDK mailing list last week.
There are 24 JEPs included in JDK 24, two of them experimental, and eight at various stages of preview.
One to note is that this release removes Windows 32-bit x86 support. JEP 479 states that all testing and development efforts targeting Windows 32-bit x86 will cease, in order to simplify the JDK’s build and test infrastructure. Other 32-bit platforms (such as ARM32) will still be supported, though the Linux 32-bit x86 port will be deprecated, for planned removal in JDK 25.
JDK 24 introduces warnings when using Java Native Interface (JNI), the long-established means of calling native code such as libraries written in C. The idea is not to deprecate JNI – though there is a new Foreign Function and Memory (FFM) API – but to provide a consistent level of warnings for both JNI and FFM API. The eventual goal is that developers wishing to call native code will have to “explicitly enable the use of JNI and the FFM API at startup”, since any interaction between Java and native code is risky.
A separate JEP, 498, provides a warning on the first time any memory-access method in the sun.misc.Unsafe namespace is invoked. These methods are already deprecated and will be removed in a future release, starting with JDK 26 which will throw an exception whenever they are used. Developers are asked to migrate to standard APIs in FFM API and also the VarHandle API.
A new performance feature, JEP 483, improves startup time by pre-loading classes ahead of time. One run of the application will monitor and cache classes, to make them available immediately on the next run. The full proposal is worth reading; the history of the cache proposal goes way back to 2004. According to the proposal, the startup time of the Spring PetClinic sample improves by 42 percent using this feature.
Another piece of Java history appears in JEP 486, which permanently disables the security manager. This has been a feature of Java from the first release, and treats all code as untrusted by default. The problem is that sandboxing code at this level is too complex, which means that few applications use it. An earlier, related, JEP stated that even when working with a framework that had an applicable policy file, such as Tomcat, “developers … still face the practically insurmountable challenge of figuring out the permissions needed by their own code and by the libraries they use.”
The security manager is disabled by default, but even the possibility of enabling it is an overhead for the JDK, adding “extraordinary complexity in the Java Platform libraries.” This burden will now be lifted.
Quantum computing brings with it the risk of easily broken encryption. JEP 496 and 497 introduce quantum-resistant modules for key encapsulation and digital signature algorithms.
The full list of new features can be found here.