OpenJDK proposes JEP 544's ahead-of-time code compilation for JDK 28

JEP 544's description makes two promises, and they are not equally easy to check. The first: startup and warmup improve because optimized native code is already available when the HotSpot JVM starts ^[2]. The second: applications reach peak performance sooner and then sustain it ^[3]. The first promise covers the first seconds of a process. The second is about the quality of that code over a long run, and it is the half I would want measured before believing it.

Proposed to Target is the stage after Candidate ^[1]. The review is expected to conclude on Monday, September 28, 2026 ^[4], seven days after the roundup that reported the change ^[1]. Until then, JDK 28 targeting is a proposal. The roundup does not include benchmark figures, the command-line flags involved, or whether Build 17 of the JDK 28 early-access builds ^[7] contains any JEP 544 code.

When benchmarks arrive, they will describe someone else's workload. For a startup number to transfer, a process has to start often enough that warmup is a real share of its life. Batch jobs and autoscaled replicas fit that description. A service that runs for weeks spends a small fraction of its uptime warming up. It collects the gain mostly at deploys and restarts.

GraalVM is still a supported path. In the same week, Oracle Labs shipped version 5.1.5 of the Graal Development Kit for Micronaut, a curated set of Micronaut modules designed to compile ahead-of-time with GraalVM Native Image and fully supported by Oracle ^[9]. GraalVM 25.4 also shipped, with new compiler optimization phases ^[10]. As JEP 544 describes it, the native code is available when the HotSpot JVM starts ^[2]. So the runtime stays HotSpot. A team with a working Native Image build gets a second option to test against it. A team that stayed on HotSpot gets a way to work on startup without changing runtimes.

The garbage collector is getting startup work too. JEP 545, Faster Startup and Warmup with ZGC, moved to Candidate with a proposal to "improve application startup and warmup by enhancing the Z Garbage Collector to acquire and prepare physical memory more swiftly and efficiently in response to application needs" ^[5]. JEP 546, Adaptive Heap Sizing for ZGC, reached Candidate at the same time ^[6]. Both sit one stage behind JEP 544 ^[2].

For a team that cares about startup, I think the right move this month is a baseline. I would add startup time and time-to-peak to whatever JDK 28 early-access testing already runs. Then the comparison numbers exist on the day a build carries JEP 544. OpenJDK asks developers to report JDK 28 bugs through the Java Bug Database ^[8].