Blog / 02

Spring Boot 4.2.0-M1 Adds AMQP 1.0, Deprecates RestTemplate

WebRestart

On August 20, 2026 the Spring team published Spring Boot 4.2.0-M1, the first milestone of the 4.2 line, carrying 113 enhancements, documentation improvements, dependency upgrades and bug fixes. Two items in it are worth acting on now even though the milestone itself is not production material: AMQP 1.0 has arrived as a first-class option, and RestTemplate's entire supporting infrastructure is deprecated for removal.

The same day brought maintenance releases on both supported lines — 4.1.1 with 98 bug fixes and 4.0.8 with 77. Those are the ones to apply to running systems today.

AMQP 1.0 lands, and the starters get shuffled

Spring Boot has spoken AMQP 0.9 through the RabbitMQ Java client for its entire life. 4.2 adds AMQP 1.0 in two flavours:

  1. Generic support built on QPid Proton, suitable for connecting to any AMQP 1.0-compliant broker.
  2. RabbitMQ AMQP 1.0 support, with more features tailored for RabbitMQ specifically.

The catch is that the artifact you already depend on is being repurposed. spring-boot-starter-amqp becomes the AMQP 1.0 starter, so every existing application has to make a decision at upgrade time. The release notes spell out both paths:

  • Staying on AMQP 0.9 "requires migrating from spring-boot-starter-amqp to spring-boot-starter-rabbitmq".
  • Moving to AMQP 1.0 on RabbitMQ "requires migrating from spring-boot-starter-amqp to spring-boot-starter-amqp-rabbitmq".

AMQP 0.9 support is not going away — it just moves house. If you do nothing and bump the version, you will pull in an AMQP 1.0 stack under a familiar artifact name, which is exactly the kind of upgrade surprise worth catching in a milestone rather than in a GA rollout.

For anyone running RabbitMQ behind a Spring Boot service, the practical move is to decide which protocol you actually want before 4.2 goes GA, then change the starter deliberately in one commit.

RestTemplate's support code is deprecated

This is the change with the widest blast radius. Quoting the release notes:

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

That covers RestTemplateAutoConfiguration, RestTemplateBuilder, RestTemplateCustomizer and the related classes. On the test side, TestRestTemplate is deprecated too, with RestTestClient as the replacement — wired up through @AutoConfigureRestTestClient.

Nothing breaks in 4.2.0-M1; deprecation is a warning, not a removal. But it is the clearest signal yet that RestClient.Builder is the supported way to make HTTP calls from a Spring application, and that integration tests built on TestRestTemplate now have a finite lifespan. The migration is mechanical for most call sites, which makes it a good candidate to do incrementally while 4.2 is still in milestones rather than under time pressure when the removal lands.

Note also that anything deprecated in 4.1 has already been removed in 4.2.0-M1. If you are on 4.1 and your build is quiet about deprecations, that is worth verifying rather than assuming.

Smaller changes that will bite in production

Three behaviour changes stand out for anyone running behind a proxy or a container platform:

Forwarded headers

With server.forward-headers-strategy=FRAMEWORK, the X-Forwarded-* variant is now the default. The format is customisable via spring.mvc.forwarded-headers.header-format or spring.webflux.forwarded-headers.header-format. If your ingress emits the RFC 7239 Forwarded header instead, check this before upgrading.

Image-based build cache for buildpacks

Building OCI images with Cloud Native Buildpacks now supports image-based caches for the build cache, so cache layers can be published to and restored from a container registry. For CI runners with no persistent Docker volume — the common case on ephemeral build agents — this removes a long-standing reason why buildpack builds were slower in CI than locally.

Metrics in tests

Tests using spring-boot-micrometer-metrics-test no longer add MeterRegistry beans to the global registry by default. If a test asserts against the global registry, it needs @AutoConfigureMetrics(useGlobalRegistry = true) or management.metrics.use-global-registry=true.

Rounding out the list: ApplicationHome and ApplicationTemp now expose a java.nio.file.Path, the JMS health check start timeout is configurable via management.health.jms.start-timeout, Jetty graceful shutdown uses GracefulHandle instead of StatisticsHandler, and Spring Boot's own configuration properties now bind through the same implementation as the binder, so ordering in your config file is preserved consistently.

What to do about it

Milestones are not for production. The useful posture is:

  1. Patch now. Move to 4.1.1 or 4.0.8 — both shipped August 20 and are pure maintenance.
  2. Audit your AMQP starter. Decide between spring-boot-starter-rabbitmq (stay on 0.9) and spring-boot-starter-amqp-rabbitmq (move to 1.0).
  3. Start the RestClient migration. Every RestTemplate and TestRestTemplate call site you convert now is one you do not convert under a removal deadline.
  4. Try 4.2.0-M1 on a branch if you build images with buildpacks in CI — the registry-backed build cache is the kind of win that justifies an early look.

If you run Jmix, this line matters more than usual: Jmix 3.0 sits on the Spring Boot 4 baseline, so Spring Boot's deprecation clock is your deprecation clock. Framework upgrades on top of Jmix and Vaadin need sequencing rather than a single big bump.

Primary sources: the Spring Boot 4.2.0-M1 announcement and its release notes, plus the 4.1.1 and 4.0.8 maintenance announcements. Spring Boot 4.1.0 itself went GA on June 10, 2026.

Planning a Spring Boot 4 upgrade and want a second pair of eyes on the sequencing? Get in touch.

All posts