What this prompt does
This prompt walks the model through migrating a Spring Boot application to a GraalVM native image — the compilation path that gives you near-instant startup and far lower memory at the cost of a slower, more fragile build. It lays out ten concrete steps, from adding native build support and running AOT processing, through the parts that actually break native builds: reflection config, dynamic proxies, runtime resource loading, and serialization. It finishes with native testing, a Docker build, a JVM-versus-native benchmark, and a CI/CD pipeline note about long build times.
The variables steer the migration toward your stack. [spring_version] sets the baseline, while [dependencies] tells the model which libraries are in play so it can flag ones lacking native support. [reflection_usage] and [proxy_usage] target the two areas where native compilation usually fails — reflection-heavy serialization and Spring's proxy-based repositories and clients — so the model generates the right reflect-config and proxy hints. [serialization_libs] covers session and cache serialization edge cases, and [build_method] picks how the image is produced, such as Paketo buildpacks with Maven.
When to use it
- You need Spring Boot startup and memory low enough for serverless or densely packed containers.
- Cold-start latency on a function platform is hurting and a native image would remove most of it.
- You are spiking native compilation and want a methodical path through the reflection and proxy failures.
- A dependency in
[dependencies]is suspected of blocking native builds and you need to confirm and work around it. - You want a fair JVM-versus-native benchmark before committing to the migration.
- Setting up CI for native images and you need to plan for the long build times up front.
Example output
Expect a step-by-step migration guide: build configuration changes, the AOT processing command and how to read its output, sample reflect-config.json entries for your [reflection_usage] areas, proxy and resource hints, a Docker native build using [build_method], and a benchmark table comparing startup time, memory, and throughput for JVM versus native. Libraries without native support come with documented workarounds rather than silent failures.
Pro tips
- List every dependency honestly in
[dependencies], including transitive ones like Lombok or Feign, since one unsupported library can stall the whole build. - Resolve
[reflection_usage]and[proxy_usage]first — these are where native builds fail, and chasing benchmarks before they are solid wastes time. - Treat
[serialization_libs]carefully if you serialize sessions or cache entries; Kryo and similar libraries often need explicit native hints. - Expect
[build_method]builds to be slow and memory-hungry; size your CI runners accordingly rather than reusing the JVM build config. - Keep a JVM build alongside the native one during migration so you can A/B behavior when something compiles but misbehaves at runtime.
