With clockwork precision, Java continues its twice-yearly release cadence, and JDK 24 is the latest milestone in this steady evolution. Released with 24 JDK Enhancement Proposals (JEPs)—a fitting match for its version number—JDK 24 is the most feature-packed update since Java adopted its time-based release schedule in 2018. While not every addition will impact developers directly (some are still in preview or incubation), a few standout enhancements are poised to significantly improve the Java development and deployment experience.
One such enhancement is JEP 483, which introduces Ahead-of-Time Class Loading and Linking, a key step under the broader umbrella of Project Leyden. This project aims to address a common pain point in Java: slow application startup times. Although the JVM offers remarkable platform independence and runtime performance via Just-In-Time (JIT) compilation, it often comes with the cost of delayed warm-up. By allowing application classes to be preloaded and linked before runtime, JEP 483 reduces this startup lag—building on earlier efforts like Application Class Data Sharing, first seen in JDK 11.
For developers focused on writing expressive, functional-style code, JEP 485 (Stream Gatherers) introduces an elegant new capability. Since Java 8, the Stream API has enabled powerful data transformations using familiar constructs like map and filter. However, while terminal operations have long supported customization through the Collector interface, intermediate operations were limited to a predefined set. JEP 485 changes that, introducing the Gatherer interface—allowing developers to define their own intermediate operations for greater control and modularity in stream pipelines.
Not every JEP adds new functionality—some mark the end of an era. JEP 486 officially removes the Security Manager, a feature present since Java’s inception. While this might seem like a security risk at first glance, the Security Manager has been largely obsolete in modern Java development. Originally designed to sandbox untrusted remote code, it’s seen declining use due to evolving security models and application deployment practices. Its removal simplifies the platform and reflects a shift toward more modern, robust security approaches in the Java ecosystem.