Spring Team on AOT Cache Handling, Null Safety with JSpecify, and Support Durations

Broadcom recently launched Spring Boot 3.5 and various Spring projects, and is working on Spring Framework 7.0 and Spring Boot 4.0 for a November 2025 debut.

Null safety in Java has recently been a special area of interest. JEP Draft 8303099, Null-Restricted and Nullable Types (Preview), is a work-in-progress and not yet a candidate for inclusion in an upcoming JDK release at this time. However, the JSpecify initiative, consisting of member organizations such as: Google (lead), Spring, JetBrains, among others, provides standard annotations for Java static analysis.

InfoQ spoke with Broadcom's Sébastien Deleuze, Spring Framework core committer, and Michael Minella, director of the open-source Spring R&D team. They answered questions on handling the Java AOT cache, finding libraries with JSpecify support, and the recent changes to the Spring support policy.

InfoQ: Users often deploy Spring Boot applications as container images stored in a registry. However, to start applications faster with Project Leyden's JEP 483, users must also store and distribute at least one Ahead-Of-Time (AOT) cache file for each container image. What are some best practices for that?

Sébastien Deleuze: Spring Boot is flexible here. It provides an extract command to unpack an executable JAR, which can be used with a Class Data Sharing (CDS) or AOT cache.

AOT cache will soon support an "express warmup" with JEP 515, Ahead-of-Time Method Profiling, proposed for Java 25, and JEP Draft Ahead-of-Time Code Compilation. The profiling data should come from an instance with realistic workload, potentially from production. The AOT cache will then not necessarily ship within the container image, and the integration will likely happen at the platform level. For example, we are integrating the AOT cache with Spring AOT in Tanzu Platform and Tanzu Spring to optimize Spring applications automatically.

As for shipping the cache within the container image, Spring Boot uses open-source Buildpacks to create container images. They can automatically do the training run with CDS and ship the resulting cache file within the container image. The AOT cache could ship the same way. It is worth noticing that unlike OpenJDK Project CRaC, CDS and AOT cache do not dump the raw Java process memory, avoiding the risk of leaking secrets or passwords. A best practice is to use a dedicated top-level container layer for the AOT cache, benefitting from caching the application layer and below.

InfoQ: The JSpecify initiative defines the semantics of null safety in Java and standardizes code annotations like @Nullable or @NonNull. Starting with Spring Boot 4.0, all Spring portfolio projects will eventually use JSpecify. But how does a Spring developer know which non-Spring libraries use JSpecify?

Deleuze: There is not yet a canonical place for libraries using JSpecify. But it's an interesting idea we will share with the working group. Outside of Spring, we have seen Google, Gradle, and GraphQL adding JSpecify annotations to their libraries.

There are three key points regarding JSpecify adoption:

First, JSpecify defines three kinds of nullness: nullable (@Nullable annotation), non-null (@NonNull annotation), and unspecified (Java default). The Java default behavior applies to libraries that do not specify the nullness of their APIs. This works well when mixing null-safe and null-unsafe code, especially when null-safe APIs use null-unsafe libraries.

Second, the granularity can be more specific than a whole library. The @NullMarked annotation is typically used at the package level to declare non-null type usage by default. Nullable type usage is then marked explicitly with @Nullable. A library can progressively add null safety this way, even at the class or method level.

Finally, JSpecify has an ongoing effort to define the nullness of the JDK itself more comprehensively, as only a subset of its APIs has nullness specified.

InfoQ: The last release of a Spring Boot generation is an LTS release. Spring Boot 2.7 from May 2022 got 18 months of free updates ("OSS support") and more than 4.5 years of paid updates (through enterprise support). Spring Boot 3.5 will only get 13 months of free updates but more than 7 years of paid ones. Why?

Michael Minella: We make minor version upgrades as simple as possible. But because a major version upgrade makes a larger ask, we have always given it more time. For instance, Spring Boot 2.7 launched in May 2022 with 18 months of OSS support and another 15 months of enterprise support. In contrast, Spring Framework 5.3, the main dependency of Spring Boot 2.7, had 50 months of OSS support and another 24 months of enterprise support. Our policy was inconsistent across the portfolio, and we wanted to do better.

So, we updated our support policy in February 2025 with two major changes. First, all support timelines now align with Spring Boot. Historically, support timelines across the portfolio depended upon the release date - different projects had different support dates. In the future, users only need to know Spring Boot's support dates: OSS support is 13 months past the Spring Boot release it aligns with, and enterprise support is 12 months past that (both rounded to the end of the month). This standardizes support durations across the portfolio and leaves only two support timeline dates: June 30 and December 31. We are currently updating the website to make it clearer.

Second, we created a unified LTS policy instead of each project doing its own: The last minor version of a major generation, like 3.5, gets five years of additional enterprise support (on top of the 13 months of OSS support and one year regular enterprise support). This provides users with over seven years of total support timeline, the longest we have ever offered.

Over the years, our community has made it clear they need more time for a major upgrade. By providing significantly more support overall and simplifying things, we meet the community's needs in the most sustainable way possible. Based on the feedback so far, the community agrees.

Developers can learn more about null-restricted and nullable types in this InfoQ news story and JSpecify 1.0.0 in this InfoQ news story. This InfoQ news story describes JEP 483, Ahead-of-Time Class Loading & Linking, the first deliverable of Project Leyden.