As a tech lead, when would you adopt JVM AOT mode (spring.aot.enabled) instead of leaving startup unoptimized or going fully native, and what trade-offs govern the decision?

## The three-way decision 1. **Do nothing** — normal JVM boot with runtime scanning/reflection. Simplest build, most flexible (runtime profile switching works), slowest startup, highest memory-at-startup. 2. **JVM AOT mode (`spring.aot.enabled`)** — pre-generate the context, run it on a standard JVM. Faster startup, lower memory, keeps JIT/tooling/debuggability. Costs: extra build step, frozen bean shape, per-deployment specialization. 3. **GraalVM native image** — compile AOT output to a native binary. Fastest startup, lowest memory, tiny footprint. Costs: long builds, GraalVM toolchain, closed-world reflection/resource configuration, reduced peak throughput (no JIT), harder profiling/debugging. (Native compilation itself is a separate build-tooling concern; here it is only the comparison endpoint.) JVM AOT mode captures a large fraction of native's startup/memory benefit for a fraction of the cost and risk. ## When JVM AOT mode is the right call - **Frequent cold starts:** serverless/FaaS on the JVM, scale-to-zero, aggressive autoscaling where each new instance's boot time is user-visible. - **High instance density / fast rollouts:** many replicas where shaving seconds and megabytes per instance compounds. - **Native curiosity without native commitment:** you want the closed-world discipline and to measure the win before investing in GraalVM. AOT mode surfaces reflection/definition problems on a JVM you can still debug. - **Throughput-sensitive services that also want faster boot:** unlike native, JVM AOT keeps the JIT, so steady-state peak performance is unchanged — you improve startup without sacrificing throughput. ## When to avoid it - **Runtime-variable wiring:** apps that flip profiles or `@ConditionalOnProperty` beans at launch to serve different environments from one artifact. The frozen model forbids this; you would need one AOT build per shape. - **Heavy dynamic bean registration** based on runtime inputs. - **Marginal benefit vs. cost:** long-lived, rarely-restarted monoliths where a few hundred ms of boot is irrelevant may not justify the build complexity. - **Immature build pipeline:** if you cannot guarantee build/run parity (same profiles, properties, classpath at processing time), AOT artifacts can silently ship the wrong bean shape. ## Operational considerations - **Per-environment builds or parity:** decide whether one AOT artifact serves all environments (only if they differ solely in `@Value`/`@ConfigurationProperties` data) or you produce per-environment AOT builds. - **CI cost:** `processAot`/`processTestAot` add build time; budget for it. - **Testing discipline:** run the suite under AOT (`process-test-aot`) so AOT-only regressions are caught in CI, not production. - **Observability parity:** because it is still the JVM, your existing profilers, heap dumps, and agents keep working — a major advantage over native for troubleshooting. - **Rollback simplicity:** you can disable AOT instantly by not setting `spring.aot.enabled`; the same jar boots the classic way (assuming the generated code is simply ignored). This makes it low-risk to trial. ## Strategic framing Treat JVM AOT mode as a **staged migration lever**: it delivers immediate value (startup/memory) and simultaneously de-risks a future native move by forcing closed-world compliance early, all while you retain full JVM debuggability. The decision hinges less on raw performance and more on whether your architecture tolerates a fixed, build-time-determined bean composition.