Spring Boot 4.0: What's New, Release History & Support Lifecycle

What Is New in Spring Boot 4.0

Spring Boot 4.0 is a major generation release built on top of Spring Framework 7.0. It introduces codebase modularization, portfolio-wide null safety via JSpecify, first-class Java 25 support (with Java 17 baseline retained), HTTP Service Client auto-configuration, built-in API Versioning, and a dedicated OpenTelemetry starter -- among many other improvements across the full ecosystem.

How does Spring Boot 4.0 modularize its codebase and why does it matter?

Spring Boot 4.0 restructures its entire codebase into smaller, more focused jars -- meaning your application only pulls in the artifacts it actually needs. In practice, this translates to leaner dependency trees, faster startup times, and better GraalVM Native Image compilation because the reachability analysis surface shrinks considerably.

Most teams will notice this change primarily during dependency resolution. Where you previously depended on a broad artifact like spring-boot-data-mongodb to get health indicators, those indicators now live in the more focused spring-boot-mongodb module. Watch out for compile errors after upgrading if your code imported internal auto-configuration classes -- those are no longer public API and have been made package-private by design.

This matters if you maintain in-house Spring Boot starters or custom auto-configurations that depended on public members of Boot's own auto-configuration classes. You'll need to reference the new module structure and rely only on documented extension points.

How do HTTP Service Clients and API Versioning work in Spring Boot 4.0?

Spring Boot 4.0 auto-configures HTTP Service Clients, letting you declare a plain Java interface annotated with @HttpExchange and have Spring generate the implementation -- no boilerplate RestClient setup required. This is a significant ergonomic improvement for teams building REST integrations.

A minimal HTTP Service Client looks like this:

@HttpExchange(url = "https://api.example.com")
public interface OrderService {

    @GetExchange("/orders/{id}")
    Order findById(@PathVariable Long id);

    @PostExchange("/orders")
    Order create(@RequestBody OrderRequest request);

}

Spring Boot will auto-create and register the implementation. You can inject OrderService directly into your beans as long as the necessary RestClient or WebClient infrastructure is present on the classpath.

API Versioning auto-configuration is now available for both Spring MVC and Spring WebFlux. You configure it through spring.mvc.apiversion.* or spring.webflux.apiversion.* properties. For advanced scenarios, you can provide beans of type ApiVersionResolver, ApiVersionParser, and ApiVersionDeprecationHandler to fully customize version negotiation behavior. Most teams adopting contract versioning will find the default property-driven setup sufficient to get started.

What observability improvements does Spring Boot 4.0 bring with OpenTelemetry and Micrometer?

Spring Boot 4.0 ships a dedicated spring-boot-starter-opentelemetry that wires in all the dependencies needed to export metrics and traces over OTLP -- no manual SDK configuration required. This starter auto-configures the OpenTelemetry SDK, making OTLP-based telemetry a first-class citizen rather than something teams had to assemble by hand.

Redis observability has also been improved. The auto-configuration now wires MicrometerTracing (based on the Observation API) instead of the narrower MicrometerCommandLatencyRecorder, which means Redis commands now produce both metrics and distributed trace spans automatically.

Additional observability improvements include:

• Support for @MeterTag on @Counted and @Timed methods, with SpEL-based expression resolution via ValueExpressionResolver.
• Support for Micrometer's @ObservationKeyValue.
• ConditionalOnEnabledTracing renamed to ConditionalOnEnabledTracingExport.
• management.tracing.enabled renamed to management.tracing.export.enabled -- update your config files before upgrading.
• Micrometer 1.16 and Micrometer Tracing 1.6 are the new baseline versions.

What are the biggest breaking changes and property renames when migrating to Spring Boot 4.0?

Spring Boot 4.0 is a major release, and the number of renamed properties and moved classes is higher than a typical minor upgrade. The team strongly recommends upgrading to Spring Boot 3.5 first and resolving all deprecation warnings before attempting the 4.0 migration.

Key property renames to address immediately:

• spring.dao.exceptiontranslation.enabled becomes spring.persistence.exceptiontranslation.enabled
• management.tracing.enabled becomes management.tracing.export.enabled
• Several MongoDB properties have been renamed -- consult the dedicated migration guide for the full list.

The underlying dependency baseline has jumped significantly. This is not a passive upgrade -- Jackson 3, Hibernate 7, Tomcat 11, Spring Security 7, Spring Framework 7, and the full Jakarta EE stack all ship with their own breaking changes. Most teams will spend the bulk of their migration effort here rather than on Boot-specific API changes.

Watch out for SSL-related behavior changes. The WILL_EXPIRE_SOON certificate status has been removed from the SSL info actuator contribution. Certificates previously reported in that state now appear as VALID. The SSL health indicator still surfaces expiring chains under the new expiringChains key in the health response detail.

Auto-configuration classes no longer expose public members. If your code accesses internal Boot auto-configuration APIs directly, expect compilation failures. This is intentional -- Boot auto-configurations were never public API, and this change enforces that at the Java level.

What new testing and developer experience features ship in Spring Boot 4.0?

Spring Boot 4.0 adds first-class support for RestTestClient, the new Spring Framework 7 test client that provides a fluent, assertion-rich API for HTTP integration testing. With a standard @SpringBootTest or @AutoConfigureMockMvc, you can inject a RestTestClient that operates directly against the underlying MockMvc instance -- no running server needed for most scenarios.

@SpringBootTest
@AutoConfigureMockMvc
class OrderControllerTest {

    @Autowired
    RestTestClient restTestClient;

    @Test
    void shouldReturnOrder() {
        restTestClient.get().uri("/orders/1")
            .exchange()
            .expectStatus().isOk()
            .expectBody(Order.class)
            .value(order -> assertThat(order.id()).isEqualTo(1L));
    }

}

For full integration tests with a live server (@SpringBootTest with a defined or random port), a RestTestClient bean targeting the running server is available for injection. This gives a consistent test API across unit and integration test modes.

Additional developer experience improvements include better error messages when configuration property binding fails due to a missing class, optimized resource lookup during DevTools restart, and a logging.console.enabled property to disable console logging without touching the logging configuration file.

Kotlin developers benefit from a new spring-boot-starter-kotlin-serialization starter and the dedicated spring-boot-kotlinx-serialization-json module, which contributes a Json bean and an HttpMessageConverter that takes precedence over other JSON converters. This matters if you're mixing Kotlin data classes with Jackson-based serialization -- the ordering is explicit and configurable via spring.kotlinx.serialization.json.* properties.