AOT Processing and the Native Build Pipeline

A traditional Spring Boot app runs on the JVM: bytecode is loaded, classes are verified, and the JIT compiler warms up over time. That gives great peak throughput but pays a cost at startup and in memory footprint.

GraalVM native images flip the model. Instead of shipping bytecode plus a JVM, you produce a single, self-contained executable where almost all the work normally done at runtime is moved to build time.

• Startup drops from seconds to tens of milliseconds.
• Memory footprint shrinks dramatically (no JIT, no class metadata bloat).
• Trade-off: longer, heavier builds and a closed-world assumption.

This makes native images ideal for serverless, CLIs, and high-density containers.

GraalVM's native compiler (native-image) performs static analysis of your entire program and only includes code it can prove is reachable. Everything must be known at build time — this is the closed-world assumption.

The features that make Spring flexible at runtime are exactly the ones that break under closed-world analysis:

• Reflection — calling methods/fields discovered by name at runtime.
• Dynamic proxies — Spring AOP, @Transactional, repository interfaces.
• Resource loading — files looked up by path at runtime.
• Serialization and runtime class generation.

Spring's AOT engine exists to bridge this gap: it analyzes your application ahead of time and emits the metadata and code GraalVM needs.