Why Java is still an industry favourite

JDK 24 introduces the largest number of new features since the time-based release schedule was adopted

Since the move to new releases every six months, Java users have really appreciated the predictability of the cycle. It has allowed them to evaluate their options and plan out adoption strategies effectively, which is key. However, I do not think this has been the main reason why 30 years after its first release we’re still talking about Java.

Java is guided by several excellent architects and has regular contributions from a wide variety of experts across industry. Together this ensures the software remains relevant to the changing needs of users and embraces innovation. That is why it is still so widely embraced across all enterprise environments.

JDK 24 demonstrates this very clearly with 24 JDK Enhancement Proposals (JEPs), the largest number of new features since the introduction of the time-based release schedule. Having been involved in the review process here are some of the features that stand out to me:

Speed matters

“Write once, run anywhere” is a slogan that has always been associated with Java. However, while it provides excellent portability, it does have performance costs as an application warms up. When launching a Java application, the JVM must load, verify, and link class files, a process that can add overhead. Part of Project Leyden, JEP 483 provides ahead-of-time class loading and linking by making application classes instantly available in a pre-loaded and pre-linked state when the JVM starts. This improves application startup times by avoiding repeated class processing overheads which is critical for microservices and serverless environments demanding rapid startup.

Adding flexibility

JEP 485 enhances the Streams API introduced in JDK 8 with Lambda expressions which was designed to process collections and provide more functional programming in mainstream Java. JEP 485 delivers a new Gatherer interface allowing developers to create custom intermediate stream operations with the same flexibility previously reserved for terminal operations. Developers can create specialised filtering patterns or implement unique transformations that combine elements in specific ways. This functionality allows teams to encapsulate that logic in a reusable gatherer instead of chaining multiple operations together or falling back to imperative code.

Streamlining security

JDK 24 is not just about adding new features, as JEP 486 disables Security Manager removing outdated functionality which is no longer relevant in today’s DevOps environment of modern containerised, cloud-native security models. This improves the overall platform by making it more streamlined and efficient, as well as removing the maintenance costs associated with supporting a legacy feature. Users should note, though, that if applications still rely on Security Manager architectural changes will be necessary to migrate to JDK 24. To be sure users understand what needs recoding, they should conduct thorough inventory assessments before upgrading affected systems.

Improving virtual threads

DevOps teams welcomed the arrival of virtual threads in JDK 21 designed to offer greater scalability in infrastructure utilisation. Unfortunately, synchronised blocks would "pin" virtual threads to carrier platform threads so that the underlying platform thread would not be released for use by other virtual threads. As a result, the monitor used by the synchronised method or block was associated with the platform thread rather than the virtual thread effectively nullifying many of the performance benefits in typical enterprise applications.

JEP 491 moves the monitor association from a platform thread to a virtual thread enabling them to acquire, hold, and release monitors independently of their carriers. This will improve performance metrics in cloud deployments and compute-intensive applications. It avoids the need for legacy codebases with synchronised blocks to be re-written and removes a significant barrier to broad virtual thread adoption across enterprise applications.

Early warning method at run time

The sun.misc.Unsafe class has been Java's unofficial interface for systems programming needs, but since JDK 9, the goal has been to move towards removing access to this JDK-internal API. Given the challenges with this class of code, JEP 498 introduces runtime warnings if memory-access methods from Unsafe are triggered. Alternatives like the VarHandle API and Foreign Function & Memory API now achieve the same outcomes in a standardised way, which is important as it pushes developers to use safer and officially supported alternatives.

Deprecating 32-bit x86 port

JDK 24 will also see the end of the 32-bit x86 port. The Windows version has already been removed and this release confirms the Linux version for removal. JEP 501 is another step in the modernisation of Java reflecting the fact that most modern systems run on 64-bit architectures. This further reduces unnecessary maintenance of older hardware architectures and aligns the adoption of JDK 24 with the widespread use of 64-bit operating systems.

In computer programming terms, Java is a well-established language celebrating its 30^th birthday this year. Like all technologies that last, crucially it continues to evolve as demonstrated in this most recent release. The regularity of Java’s six-month release cycle gives users a reliable timetable for expected improvements rather than having to scramble to manage ad hoc updates. JDK 24 delivers features that developers and users need whether it is improving application warm-up times or virtual threads. It also improves Java by removing features that are dated to reduce maintenance costs and drive better performance.

September 2025 will see the next long-term support release (JDK 25), so now is the time assess this current crop of new features and plan adoption strategies, because it is safe to say users can expect further improvements in the next release which will continue to demonstrate the adaptability of Java to respond to innovations such as AI and changing infrastructure demands, such as the move to cloud-native applications.

Simon Ritter is deputy CTO at Azul