Java's Cloud-Native Leap: JEP 544 Cuts Startup Time 65-80% with AOT Compilation

Java's Slow Startup Problem in Cloud-Native Era

Java has long been criticized for slow startup and long warm-up times, which hinder its adoption in microservices, serverless, and elastic scaling scenarios. While JIT compilation eventually delivers peak performance, the "climb" can take minutes, leaving newly scaled instances at half capacity.

JEP 544: Ahead-of-Time Code Compilation Targets JDK 28

In September 2026, OpenJDK chief architect Mark Reinhold announced that JEP 544 (Ahead-of-Time Code Compilation) is targeted for JDK 28. The feature passed the JEP 2.0 process without opposition and appears in JDK 28 early-access build 20 (October 2026).

By compiling application code to native code during a training run and storing it in an AOT cache for subsequent production runs, optimized native code becomes immediately available at HotSpot JVM startup, improving startup and warm-up times. If production workloads diverge, the JVM dynamically recompiles native code to maintain peak performance, combining the best of AOT and JIT.

How JEP 544 Works

Unlike GraalVM Native Image, which requires a closed-world assumption and heavy build-time configuration, JEP 544 stays within the standard HotSpot JVM. It records class loading, linking state, method profiling data, and compiled native code into an AOT cache during a training run. At production startup, the JVM loads this cache, skipping interpretation and tiered compilation entirely.

Analogy: previously Java apps were like athletes warming up for two hours each shift; now the warm-up is recorded and replayed, so they start at peak condition.

Project Leyden's Five-Year Roadmap

JEP 544 is the capstone of Project Leyden, which incrementally cached more runtime artifacts:

JEP 483 (JDK 24): AOT class loading and linking (initial AOT cache).

JEP 514 (JDK 25 LTS): Single-command cache creation and usability improvements.

JEP 515 (JDK 25 LTS): Caching AOT method profiling data to accelerate warm-up.

JEP 516 (JDK 26): Cache compatibility with any GC, including ZGC.

JEP 544 (JDK 28): AOT code compilation — caching the actual compiled native code, the final and most critical piece.

The community views this as Leyden entering its final sprint.

Benchmark Results: 65–80% Startup Reduction

On a dual-core Linux/x64 machine, five benchmark applications built on popular frameworks showed that adding AOT code compilation on top of existing class/object caching reduced startup time from ~50–70% to ~65–80%. An application that previously took 10 seconds to start and minutes to warm up could reach peak performance in 2–3 seconds. This is transformative for serverless (billed per 100ms) and Kubernetes elastic scaling.

Comparison with GraalVM Native Image

GraalVM Native Image — "closed world": all classes must be known at build time; no dynamic class loading; reflection, dynamic proxies, JNI require extra metadata; heavy build process; often requires maintaining two build pipelines.

JEP 544 — "open world": uses the full HotSpot JVM; reflection, dynamic class loading, all GCs (including ZGC) work unchanged. If production load differs from training, the JVM dynamically re-JIT compiles to sustain peak performance.

Observers call this the true "best of both worlds."

Usage: Three-Step Workflow

# 1. Training run: record class loading and execution information
java -XX:AOTMode=record -XX:AOTCacheOutput=app.aot -cp app.jar com.example.Main

# 2. Offline AOT cache creation (includes native code generation)
java -XX:AOTMode=create -XX:AOTCacheOutput=app.aot -cp app.jar

# 3. Production run: mount the cache directly
java -XX:AOTCache=app.aot -jar app.jar

No application, library, or framework code changes are required — a stated design goal.

Caveats and Considerations

Not a free lunch: Training runs and cache generation must be integrated into CI/CD and release pipelines; cache artifacts must be versioned with the application; significant workload changes require re-training.

JDK 28 is non-LTS: Expected March 2027; enterprises may wait for backport to an LTS line.

Training load representativeness: The cache quality depends on how well the training run mirrors production. Iterative training and cache merging remain active community discussions.

Conclusion

JEP 544 changes the fundamental Java performance model from "slow start, gradual climb" to "instant peak, sustained throughout." Together with JDK 28's ZGC startup optimizations (JEP 545, 546), it plugs the last major gap for Java in cloud-native environments. It does not replace JIT but collaborates with it, giving Java both AOT's instant startup and JIT's adaptive optimization. The 20-year "Java starts slow" narrative may finally be rewritten.