The Spring Team on Spring Framework 7 and Spring Boot 4

Introduction

Broadcom released Spring Framework 7.0 and Spring Boot 4.0 (announced here and here) in November 2025. This new generation introduces first-class REST API versioning, JSpecify annotations for standardized null safety across the Spring portfolio, and built-in resilience features, including retry and concurrency throttling. Spring Boot 4 migrates to Jackson 3 for JSON processing and splits the monolithic autoconfigure JAR into modules. Spring Framework 7 keeps the JDK 17 baseline while embracing JDK 25, but adopts Jakarta EE 11 and Kotlin 2.2 as new baselines.

Some more Spring projects published major releases after the Spring Boot 4 release: Spring Cloud, Spring Modulith, and Spring Shell. Spring Boot 4.1 is expected in May 2026.

InfoQ recently spoke with key members of the Spring team at Broadcom about the significant architectural and functional advancements introduced in Spring Framework 7 and Spring Boot 4. This conversation explores the strategic shift toward core resilience by integrating features such as retry and concurrency throttling directly into the framework, alongside the performance benefits of modularizing auto-configurations.

The panel also examines the implementation of first-class support for HTTP API versioning and the transformational role of AI coding tools in the modern developer's workflow. Finally, the team provides practical guidance on navigating the upgrade path from Spring Boot 3 to 4, highlighting the specific tools, compatibility modules, and community resources available to streamline the transition for enterprise applications.

The Panelists

• Phil Webb, co-creator and lead of Spring Boot
• Sam Brannen, core Spring Framework committer and JUnit 5 maintainer
• Rossen Stoyanchev, Spring Framework committer: Spring MVC, WebFlux
• Mark Pollack, founder of the Spring AI project
• Martin Lippert, lead of the Spring Tools projects
• Michael Minella, open-source Spring R&D team Director, fmr. Spring Batch lead

InfoQ: What's the real-world performance impact of Spring Boot 4's modularization of auto-configurations? And how do you think it will affect third-party starter development?

Phil Webb: Performance wasn’t the primary driver of the modularization work; however, I think we’ll see some improvements around startup times. A lot of auto-configuration classes only kick in when a specific class is found on the classpath. With earlier versions of Spring Boot, we needed to check a lot of classes on each application run. The modularization means that we won’t need to check as much.

Another small performance benefit comes from the size of the uber jar you create. Only picking the modules you need means that your jar is smaller. This means there are fewer bytes that need to be read.

InfoQ: Why integrate Spring Retry into the Spring Framework rather than keeping it modular?

Sam Brannen: Core resilience features constitute a major theme in Spring Framework 7, and under that umbrella, we are introducing both retry support and annotation-driven concurrency throttling.

Historically, the Spring community has relied on the Spring Retry project for various forms of retry support. However, for the 7th generation of the framework, we decided to incorporate core retry support at the lowest level of the Spring portfolio, in Spring Framework itself. Although this support was naturally inspired by the Spring Retry project, we completely redesigned it as a minimal set of core retry features in the spring-core and spring-context modules. This enables all Spring developers to make use of RetryTemplate and @Retryable without the need to pull in an additional dependency. In other words, core retry support is always available, and even the Spring Framework itself can naturally build on top of these core retry features, for example, in RestClient.

Regarding the feature set, RetryTemplate enables developers to introduce programmatic retry support directly in their code, with full control over the retry policy and backoff strategy. Whereas @Retryable supports a declarative approach where developers annotate a class or method with @Retryable and specify retry and backoff configuration via annotation attributes. @Retryable naturally supports imperative programming models; however, unlike the support in the Spring Retry project, Spring Framework's @Retryable annotation can also be applied to methods with reactive return types. Spring decorates the reactive pipeline with Project Reactor's Retry spec. For non-reactive return types, Spring simply configures a RetryPolicy and delegates to a RetryTemplate.

Last but not least, @ConcurrencyLimit allows developers to configure a concurrency limit for a given method invocation. Concurrency throttling effectively protects the target resource from being accessed from too many threads at the same time, similar to the effect of a pool size limit for a thread pool or a connection pool that blocks access if its limit is reached. Such limiting is particularly useful with Virtual Threads, where there is generally no thread pool limit in place.

InfoQ: Spring Framework 7 implements API versioning with HTTP headers. What are your plans for working with other communities, such as JavaScript, Python, and .NET, to make these versions easily accessible to them?

Rossen Stoyanchev: A Spring Framework 7 server application can choose from a range of API version strategies, including path, header, query parameter, or media type parameter. The decision involves a number of considerations.

A key factor is the depth of change expected. For example, path-based versioning can accommodate deeper structural changes in the underlying domain model. Header and query parameter versions are useful where a more lightweight change is expected, and allow versioning controller mappings incrementally as needed.

Another factor is the existence of different REST API guidelines. For example, if you need or decide to follow the Microsoft REST API guidelines, you’ll choose between a path version such as v1.0 or a query parameter named api-version. But if you follow the Zalando RESTful API guidelines, you’ll use a media type parameter named version.

Given the wide range of choices and practices, Spring Boot does not make out-of-the-box decisions. Applications must explicitly enable API versioning and, at the same time, choose an API version strategy along with other details such as a header or query parameter name, version format (e.g., semantic versioning vs date), and more. The decision is in the developer’s hands.

From the beginning, when we set out to provide API versioning support, we knew that this was a nuanced problem space with many opinions and no one-size-fits-all solution. So rather than mandating or guiding toward a specific set of options, our goal was to provide the building blocks that empower developers and support them with whatever choices they make.

From a client perspective, you need to follow the expectations of the server. For example, if you write a client to access GitHub’s REST API, you’ll need to use a header called X-GitHub-Api-Version. In that sense, the details of the strategy have less to do with implementation technology and more with application-specific REST API design choices.

Spring’s RestClient and WebClient builders allow you to configure API versioning once, so that when requests are made, application code doesn’t need to fiddle with HTTP request details. Likewise, the HttpExchange annotation of HTTP interface clients now supports a version attribute and is decoupled from HTTP request details, which can be set in configuration without changing request access code. JavaScript, Python, .NET, and other client libraries are expected to provide similar features and configurability.

InfoQ: What's your experience of working with AI coding tools like Claud Code, GitHub Copilot, or Google Gemini, on Spring projects? How do you think the work of a Spring developer will change with these new tools?

Mark Pollack: My experience has been transformational. I don’t think developers of any flavor will be coding in the same way we have been for the past 20 years anymore. For developers who are already seasoned and have good design skills, the interaction with modern coding tools is a game-changer. It will take time to see which developers learn to use these tools effectively. So, I’m quite bullish on how transformative these tools are for coding. Others disagree, especially the folks who like to ask AI the question "how many Rs are in Strawberry" and enjoy watching the mistakes made in a one-shot answer, but in short, that is my personal experience.

InfoQ: Files with detailed rules, guidelines, and best practices can direct AI coding tools to produce better code for us. For Claude Code, for instance, these files could be skills or subagents. What are your plans for publishing such files? For instance, they could be project-specific, such as Spring Web MVC or Spring Data, or horizontal, such as covering security or performance.

Martin Lippert: This is indeed an interesting topic, and we are actively looking into this both from what we could do directly as well as what we could do via partnerships, but at the moment, everything is from a research perspective. The upcoming Spring Tools 5 release will be the first generation of the Spring Tools, for example, that will be ready for AI coding environments and will include features to provide deeper Spring insights into the projects in your workspace to the coding assistant around you. What we are going to do beyond that is not yet decided.

InfoQ: Spring Boot 4 introduces upgrade challenges for many developers, including new package names for Jackson 3 and JSpecify nullability annotations. What tools or AI support do developers have for upgrading their Spring Boot 3 applications?

Phil Webb: We’re very fortunate to have an active developer community that tried early milestones and gave us great feedback. This resulted in us refining a few decisions to help folks who are upgrading. For example, we introduced a Jackson 2 module since we know that a lot of the ecosystem hasn’t yet moved to Jackson 3.

We’ve also been upgrading our own internal applications to get a feel for the pain involved. We’ve been pleasantly surprised that a lot of typical Spring Boot applications can be upgraded without too much effort. For example, a lot of package renames are in auto-configuration classes that users don’t typically import directly. We’ve also been careful to provide tooling support for renamed configuration properties so that IDEs and the property migrator jar can help you quickly find the replacements.

Developers looking to upgrade should start with the migration guide on our wiki. We also anticipate that the community may step up and provide OpenRewrite recipes for common migration issues, as has happened in the past. Customers who have purchased support from Broadcom can also take advantage of the Application Advisor tool.

Of course, no major upgrade is going to be completely painless. We do expect users with deeper Spring Boot integrations to have to spend a little more time on the upgrade than regular applications.

InfoQ: Spring Boot 2.7 had 12 more months of free maintenance releases when Spring Boot 3 was released, followed by another 37 months of paid releases. Spring Boot 3.5 now has 7 more months of free maintenance releases left, ending in June 2026, followed by another 72 months of paid releases. How do you think this will affect enterprise adoption of Spring Boot 4?

Michael Minella: From the interactions we have had with our users, a few months of open source support one way or the other has not moved the needle for them when it comes to the timing of their upgrades. The community has been aware of the upcoming major versions for over a year now, and those who choose to stay on open-source-supported versions have been engaged over that time. To help our users be involved as early as possible, we began releasing milestones and release candidates to Maven Central for the first time over this cycle, resulting in a noticeable increase in feedback, allowing us to further polish these releases.

For most users, however, the large extension of the enterprise support duration has had a material impact on how they manage their application portfolio. Whether it be choosing to take more time to do a major upgrade or using extended support to provide that peace of mind on an application they plan to sunset and do not want to invest in, both are practical options with our current offerings.

We understand all of those scenarios. While we firmly believe that staying up to date with the latest releases is the best option for our users (and we provide tooling via Application Advisor to do so), we have structured the support offerings to enable all options because not every application requires the same level of investment.

Conclusions

Spring Boot 4 brings modularized auto-configurations that should improve startup times by reducing classpath checks, along with smaller uber jars. Spring Framework 7 adds built-in retry support via RetryTemplate and @Retryable — including reactive return types — plus @ConcurrencyLimit for throttling, especially useful with Virtual Threads. API versioning supports path, header, query parameter, and media type strategies, with no default choice imposed by Spring Boot. The Spring team sees AI coding tools as transformational and plans to ship Spring Tools 5 with AI-ready features, though broader AI guidance files remain in research.

Upon upgrading to Spring Boot 4, the team expects most typical applications to migrate with reasonable effort. A Jackson 2 compatibility module eases the transition to Jackson 3, and IDE tooling helps with renamed configuration properties. The migration guide on the Wiki is the best place to start, with the community-provided OpenRewrite recipes automating much of the migration. Broadcom support customers can also use the Application Advisor tool.

Regarding support timelines, the Spring team says the shortened free open-source support window for Spring Boot 3.5 (7 months after Spring Boot 4's release) has not significantly affected upgrade timing for most users. The extended enterprise support duration — now 72 months of paid releases — gives organizations flexibility to manage upgrades at their own pace or maintain applications they plan to sunset.