As announced in "the state of HTTP clients in Spring" blog post
(https://spring.io/blog/2025/09/30/the-state-of-http-clients-in-spring),
the deprecation timeline for `RestTemplate` was announced last November
and docs were updated accordingly.
This commit `@Deprecate` `RestTemplate` and related types for removal to
send a stronger signal to our community.
The actual removal is scheduled for Spring Framework 8.0 (not yet
scheduled).
Closes gh-36574
Prior to this commit, the `SockJsClient` would use the
`RestTemplateXhrTransport`. `RestClient` is a modern replacement for
RestTemplate and should be used instead.
This commit introduces the `RestClientXhrTransport` variant as an
immediate replacement.
Closes gh-36566
Although this commit also changes the visibility of some test methods
to package-private, the remainder of that task will be addressed in
conjunction with gh-36496.
Closes gh-36495
Prior to this commit, the `StandardWebSocketUpgradeStrategy` would get
the HTTP headers from the handshake request and store them in the
WebSocket session for the entire duration of the session.
As of gh-36334, Spring MVC manages HTTP directly with a native API
instead of copying them. This improves performance but also uncovered
this bug: we cannot keep a reference to HTTP headers once the HTTP
exchange is finished, because such resources can be recycled and reused.
This commit ensures that the handshake headers are copied into the
session info to keep them around for the entire duration of the session.
Without that, Tomcat will raise an `IllegalStateException` at runtime.
This was already done for WebFlux in SPR-17250, but the latest header
management changes in Framework uncovered this issue for the Standard
WebSocket container case.
Fixes gh-36486
Prior to this commit (and despite the changes made in commit
4593f877dd), WebSocketHttpHeaders was not compatible with the
HttpHeaders(HttpHeaders) constructor or the copyOf(HttpHeaders) and
readOnlyHttpHeaders(HttpHeaders) factory methods.
To address that, this commit revises the implementation of
WebSocketHttpHeaders so that it only extends HttpHeaders, analogous to
ReadOnlyHttpHeaders. In other words, WebSocketHttpHeaders no longer
stores or delegates to a local HttpHeaders instance.
Closes gh-35792
Since HttpHeaders no longer implements MultiValueMap (see gh-33913),
a few interoperability issues have arisen between HttpHeaders and
WebSocketHttpHeaders.
To address those issues, this commit:
- Revises addAll(HttpHeaders), putAll(HttpHeaders), and putAll(Map) in
HttpHeaders so that they no longer operate on the HttpHeaders.headers
field.
- Overrides addAll(String, List), asSingleValueMap(), and
asMultiValueMap() in WebSocketHttpHeaders.
- Deletes putAll(HttpHeaders), putAll(Map), and forEach(BiConsumer) in
WebSocketHttpHeaders, since they do not need to be overridden.
This commit also removes unnecessarily overridden Javadoc in
WebSocketHttpHeaders and revises the implementation of several methods
in HttpHeaders so that they delegate to key methods such as get()
instead of directly accessing the HttpHeaders.headers field.
See gh-33913
Closes gh-35792
Undertow does not support Servlet 6.1, we need to remove compatibility
tests as well as Undertow-specific classes for WebSocket and reactive
support.
Closes gh-35354
- Improve Javadoc.
- Suppress warnings for "removal".
- Update copyright headers.
- Migrate several tests from:
- MappingJackson2MessageConverter to JacksonJsonMessageConverter
- Jackson2JsonEncoder to JacksonJsonEncoder
- Jackson2JsonDecoder to JacksonJsonDecoder
- Jackson2SmileEncoder to JacksonSmileEncoder
- Jackson2ObjectMapperBuilder to JsonMapper and XmlMapper
- MappingJackson2JsonView to JacksonJsonView
- MappingJackson2HttpMessageConverter to JacksonJsonHttpMessageConverter
- MappingJackson2XmlHttpMessageConverter to JacksonXmlHttpMessageConverter
This change removes the `MultiValueMap` nature of `HttpHeaders`, since
it inherits APIs that do not align well with underlying server
implementations. Notably, methods that allows to iterate over the whole
collection of headers are susceptible to artificially introduced
duplicates when multiple casings are used for a given header, depending
on the underlying implementation.
This change includes a dedicated key set implementation to support
iterator-based removal, and either keeps map method implementations that
are relevant or introduces header-focused methods that have a similar
responsibility (like `hasHeaderValues(String, List)` and
`containsHeaderValue(String, String)`).
In order to nudge users away from using an HttpHeaders as a Map, the
`asSingleValueMap` view is deprecated. In order to offer an escape
hatch to users that do make use of the `MultiValueMap` API, a similar
`asMultiValueMap` view is introduced but is immediately marked as
deprecated.
This change also adds map-like but header-focused assertions to
`HttpHeadersAssert`, since it cannot extend `AbstractMapAssert` anymore.
Closes gh-33913
This commit updates the whole Spring Framework codebase to use JSpecify
annotations instead of Spring null-safety annotations with JSR 305
semantics.
JSpecify provides signficant enhancements such as properly defined
specifications, a canonical dependency with no split-package issue,
better tooling, better Kotlin integration and the capability to specify
generic type, array and varargs element null-safety. Generic type
null-safety is not defined by this commit yet and will be specified
later.
A key difference is that Spring null-safety annotations, following
JSR 305 semantics, apply to fields, parameters and return values,
while JSpecify annotations apply to type usages. That's why this
commit moves nullability annotations closer to the type for fields
and return values.
See gh-28797
StandardWebSocketUpgradeStrategy is the common replacement on Tomcat, Undertow and all EE servers. JettyRequestUpgradeStrategy remains the preferred choice on Jetty.
Closes gh-33744
This commit updates SpringConfiguratorTests to not rely on classpath
scanning as it could have side effect. In this particular case, the
configuration class that sources the scan is detected again, leading
to bean overriding.
Irrespective of that, adding more code in that package may have side
effect as they could be scanned as well.
Closes gh-32535
Sam Brannen
rstoyanchev
Brian Clozel
Juergen Hoeller
Jeroen Meijer
Spring Builds
Sébastien Deleuze
Sébastien Deleuze
Simon Baslé
Stéphane Nicoll