Support generating Leyden AOT cache from integration tests

[vpelikh]

Problem Statement

Spring Boot 3.3 introduced CDS support and laid the groundwork for Project Leyden. Java 24 brought the AOT cache (JEP 483) to production, and Java 25 / 26 have stabilised and enhanced it further — including compiled-code caching via JEP 515 in Java 25. These JDK versions are already released and widely adopted. Today the recommended way to generate an AOT cache is a dedicated training run (e.g. -XX:AOTMode=record -Dspring.context.exit=onRefresh) or via Buildpacks environment variables. This workflow adds extra steps to CI/CD pipelines — developers already write thorough integration tests that exercise realistic code paths, yet those tests cannot be used to produce the cache.

Quarkus successfully demonstrated that integration tests are a natural and effective training workload: @QuarkusIntegrationTest tests can be run with a single flag to generate app.aot. Spring Boot should offer a similarly streamlined experience, allowing teams to leverage their existing integration-test suites to create the AOT cache without additional deployment tooling.

Use Case

1. A Spring Boot project has a suite of @SpringBootTest integration tests that exercise REST endpoints, database access, messaging, etc.
2. The developer (or CI system) runs those tests with a special JVM flag or Maven/Gradle property.
3. During test execution, the JVM records class-loading, method-profiling data, and compiled-code information (Leyden recording mode, with full support from Java 25’s JEP 515).
4. At the end of the test run, an optimised .aot (or .jsa) cache file is produced.
5. The same cache file is then shipped with the container image, giving the production application the full benefit of Leyden’s startup and warmup improvements.

Proposed Solution

Spring Boot could provide:

1. A dedicated test-listener / AotCacheTestExecutionListener that hooks into the Spring TestContext Framework and sets the correct JVM flags for AOT recording. The Spring Framework already has TestContextAotGenerator for build-time AOT processing; a similar runtime listener for Leyden could be introduced.

2. Maven/Gradle task integration — analogous to how BP_JVM_AOTCACHE_ENABLED works for Buildpacks — so that a command like:

   ./mvnw verify -Dspring.aot.cache.record=true

   or

   ./gradlew test -PspringAotCache record

   would automatically set the necessary JVM arguments (-XX:AOTMode=record, -XX:AOTConfiguration=..., etc.) for the test task.

3. A configuration surface (spring.aot.cache.* properties) for specifying the output path, whether to combine Spring AOT processing with the Leyden cache, and which test slices or profiles to use during training.

4. Documentation in the reference guide explaining the integration-test workflow, constraints (e.g., the classpath must use standard JDK class loaders, the extracted JAR layout must be used), and the performance trade-offs.

Challenges to Address

• Class-loader compatibility: Leyden only caches classes loaded by the standard JDK class loaders, so the Spring Boot “executable JAR” layout must first be extracted. The integration-test pipeline will need to handle this automatically.

Inspiration from Quarkus

The Quarkus community published a detailed write-up of its own Leyden integration. Key takeaways that could influence Spring Boot’s design:

• A dedicated aot-jar packaging that delegates class loading to the JDK loader and collects service descriptors.
• Automatic use of @QuarkusIntegrationTest tests as the training workload.
• A single flag quarkus.package.jar.aot.enabled=true that activates the entire pipeline, including container-image building.
• Measured startup improvements of 70-80% compared to the default JVM mode.

Additional Context

• Quarkus Leyden integration blog: https://quarkus.io/blog/leyden-2/