AOT and native images: optimize the deployment case
Prerequisites: 01-ecosystem
What moves from runtime into the build?
Goal & mental model verified
Native images compile under a closed-world assumption. Spring AOT analyzes application assembly ahead of runtime and generates supporting assets. Dynamic bean-graph changes and reflection/resource access can require different handling.
[S58] [S14]Worked example · design exercise synthesis
A rarely invoked quote utility may benefit from reduced startup overhead. A long-running service may favor JVM JIT behavior; measure both against the actual deployment workload.
[S58] [S14]Engineering decision synthesis
Evaluate native deployment when startup and footprint constrain the product. Accept build complexity and compatibility work only when the measured operational benefit matters.
[S58] [S14]Pitfall & diagnosis synthesis
A successful JVM run does not prove native compatibility. Runtime configuration that changes which beans exist can conflict with build-time assembly assumptions.
[S58] [S14]Improve & validate synthesis
Test the native artifact itself, including serialization, resources and integrations. Compare cold start, steady-state throughput, memory and build time under equivalent conditions.
[S58] [S14]Check yourself: Can native mode freely rebuild its bean graph from runtime properties?
No. AOT/closed-world constraints limit runtime changes to application assembly.