Spring Boot 4.2.0 M1 Release Notes

Spring Boot 4.2.0-M1 Release Notes

Upgrading from Spring Boot 4.1

Deprecations from Spring Boot 4.1

Classes, methods and properties that were deprecated in Spring Boot 4.1 have been removed in this release. Please ensure that you aren’t calling deprecated methods before upgrading.

Deprecation of (Test)RestTemplate Support

With Spring Framework 7.1 deprecating RestTemplate for removal, Spring Boot’s supporting infrastructure has been deprecated as well, in favor of RestClient:

RestTemplateAutoConfiguration and RestTemplateObservationAutoConfiguration.
RestTemplateBuilder, RestTemplateBuilderConfigurer, and RestTemplateBuilderClientHttpRequestInitializer.
RestTemplateCustomizer, RestTemplateRequestCustomizer, and ObservationRestTemplateCustomizer.
MockRestServiceServerAutoConfiguration, MockServerRestTemplateCustomizer, and RootUriRequestExpectationManager (in spring-boot-restclient-test).

Applications that build a RestTemplate using the auto-configured RestTemplateBuilder should migrate to RestClient.Builder instead. Customizations applied through a RestTemplateCustomizer bean have an equivalent using RestClientCustomizer, and tests relying on @RestClientTest with MockRestServiceServer should configure a RestClient.Builder rather than a RestTemplateBuilder.

The reference documentation section on "Calling REST Services with RestClient and WebClient" no longer covers RestTemplate.

For tests, TestRestTemplate is deprecated as well. There are several options for replacements, but RestTestClient is an obvious choice. You can annotate your test class with @AutoConfigureRestTestClient and get a RestTestClient injected that uses a mock transport or issues requests against a live server, depending on the type of test. The API is very similar to RestClient and has built-in assertions.

You can learn more in the Spring Framework reference documentation about RestTestClient.

AMQP 0.9 support moved

With the introduction of AMQP 1.0 support, users should make a choice when upgrading:

Stay on AMQP 0.9 support, which requires migrating from spring-boot-starter-amqp to spring-boot-starter-rabbitmq.
Use AMQP 1.0 support, which requires migrating from spring-boot-starter-amqp to spring-boot-starter-amqp-rabbitmq.

Forward HTTP headers behavior change

As of Spring Framework 7.1, using the ForwardedHeaderFilter requires you to specify whether it should use the standard "Forwarded" or "X-Forwarded" headers. We have reflected this behavior change in Spring Boot: when server.forward-headers-strategy=FRAMEWORK strategy is selected, the "X-Forwarded-*" headers variant will be used by default, but can be customized with spring.mvc.forwarded-headers.header-format or spring.webflux.forwarded-headers.header-format. Note that the FRAMEWORK strategy now only applies to Spring MVC or Spring WebFlux applications, whereas this would apply to Servlet applications in general.

The native embedded HTTP server support (Tomcat, Jetty and Reactor Netty) has improved and you can now also select the header format with configuration properties. See the reference documentation on Running Behind a Front-end Proxy Server for more information.

Harmonization of Sets and Maps in Configuration Properties

Configuration properties that are shipped by Spring Boot now use the same implementation as the binder for consistency. Binding to those types now keeps the order specified in the configuration file consistently.

You may be impacted if you were relying on the order by reading the raw Set or Map.

Minimum Requirements Changes

New and Noteworthy

Tip	Check the configuration changelog for a complete overview of the changes in configuration.

AMQP 1.0 Support

Support for AMQP 1.0 has been added:

Generic support using QPid Proton, suitable to connect to any AMQP 1.0-compliant broker. Check the Spring AMQP reference guide for more details.
RabbitMQ AMQP 1.0 Support that has more features tailored for RabbitMQ.

The existing AMQP 0.9 support is still available, and users should migrate to spring-boot-starter-rabbitmq.

Image-Based Build Cache Support for Buildpacks

Building OCI images using Cloud Native Buildpacks now supports image-based caches for the build cache (buildCache). This allows cache layers to be published to and restored from a container image registry in addition to local Docker volumes and bind mounts.

You can configure an image cache in the Gradle plugin or Maven Plugin.

Note that buildWorkspace and launchCache continue to support local caches (Docker volumes and bind mounts) only.

Dependency Upgrades

Spring Boot 4.2.0-M1 moves to new versions of several Spring projects:

Numerous third-party dependencies have also been updated, some of the more noteworthy of which are the following:

Miscellaneous

Apart from the changes listed above, there have also been lots of minor tweaks and improvements including:

ApplicationHome and ApplicationTemp exposes convenient java.nio.file.Path.
Plugin management for hibernate-maven-plugin has been added. If you were providing a version, you can omit it if you are using Maven with spring-boot-starter-parent.
The timeout to start a JMS connection for health check is now configurable using management.health.jms.start-timeout.
Graceful shutdown with Jetty uses GracefulHandle rather than StatisticsHandler.
The global timeout can be configured using RetryPolicySettings.
Tests that use spring-boot-micrometer-metrics-test no longer add their MeterRegistry beans to Micrometer’s global registry by default, preventing meter registries from pinning cached application contexts between tests. Use @AutoConfigureMetrics(useGlobalRegistry = true) or set management.metrics.use-global-registry=true explicitly to opt back in.