Java's new AOT cache feature is in a rough state

Java’s ahead-of-time (AOT) cache records an application’s class loading, linking, and method activity during a training run so later launches can skip some startup work. It builds on class-data sharing and differs from GraalVM Native Image: the application still runs on a JVM, retains Java’s dynamic features, and falls back to ordinary runtime work if the cache cannot be used. The feature has grown across JDK releases, from class loading and linking in JDK 24 to profiling in JDK 25, object caching in JDK 26, and planned code compilation in JDK 28. The promise is easier startup improvement without application changes, but deploying caches beyond the machine that created them exposes important hazards.

The central problem is that class linking can generate cached machine-code adapters tied to the training CPU’s instruction-set features. On a target machine lacking those features, calling an adapter can crash the JVM with an illegal-instruction error - an especially serious risk when caches are built in CI or containers and shipped to users or mixed-hardware servers. The workaround is to disable adapter caching during cache generation with the undocumented diagnostic flags `-XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching`; JDK 27 is expected to check CPU compatibility before using cached adapters. JDK 28’s broader compiled-code cache will also require an exact CPU-feature match, which avoids crashes but may make caches unusable across different processors. The account argues that a practical compatibility mode is needed and recommends inspecting AOT behavior through JVM logging.