Spring Framework 7.0 Release Notes

This is a preview of the Spring Framework 7.0 release, scheduled for November 2025.

Upgrading From Spring Framework 6.2

Baseline upgrades

Spring Framework 7.0 does not change the JDK baseline, expecting a JDK 17-27 compatibility range. This new generation raises its minimum requirements with the following libraries:

Jakarta EE 11 (Tomcat 11+)
Kotlin 2.x, see #33629
JSONassert 2.0, see #33799
GraalVM 23 with the new "exact reachability metadata" format.

Removed APIs

Spring JCL has been retired

The spring-jcl module has been removed in favor of Apache Commons Logging 1.3.0. This change should be transparent for most applications, as spring-jcl was a transitive dependency and the logging API calls should not change. See #32459 for more details.

Path mapping options

Several path mapping options have been marked for removal since 6.0. They are now removed completely. This includes:

suffixPatternMatch/registeredSuffixPatternMatch for annotated controller methods
trailingSlashMatch for extensions of AbstractHandlerMapping
favorPathExtension/ignoreUnknownPathExtensions and underlying PathExtensionContentNegotiationStrategy and ServletPathExtensionContentNegotiationStrategy for content negotiation, configurable through ContentNegotiationManagerFactoryBean and in the MVC Java config
matchOptionalTrailingSeparator in PathPatternParser

Other removals

Many other APIs and features were removed as part of #33809, including:

ListenableFuture in favor of CompletableFuture
OkHttp3 support
WebJars support with org.webjars:webjars-locator-core in favor of org.webjars:webjars-locator-lite

Deprecations

the <mvc:* XML configuration namespace for Spring MVC is now deprecated in favor of the Java configuration variant. There are no plans yet for removing it completely but XML configuration will not be updated to follow the Java configuration model. Other namespaces (like <bean>) are NOT deprecated.
The Kotlin team has shared there intention to remove the JSR 223 support in a future Kotlin 2.x release. As a result, Kotlin scripts template support in Spring has been deprecated.

Null Safety

Spring nullness annotations with JSR 305 semantics are deprecated in favor of JSpecify annotations. The Spring Framework codebase has been migrated to Specify and now specifies the nullness of array/vararg elements and generic types. You can find more details on how to migrate in this dedicated section of the reference documentation.

HttpHeaders changes

The HttpHeaders API has been revisited in 7.0; this class does not extend the MultiValueMap contract anymore. Underlying servers treat headers more like a collection of pairs and many map-like operations do not behave nor perform well, because headers are case-insensitive in the first place. We removed several methods as a result and introduced fallbacks as immediately @Deprecated, like HttpHeaders#asMultiValueMap. Please consider other methods as much as possible. See gh-33913 for more details.

Servlet 6.1 and WebSocket 2.2 baselines

Spring Framework 7.0 adopted Jakarta Servlet 6.1 and WebSocket 2.2 as new baselines for web applications. In practice, this means that applications should be deployed on recent Servlet containers like Tomcat 11+ and Jetty 12.1+.

We also took this opportunity to update our HTTP mock support with MockHttpServletRequest/MockHttpServletResponse, better aligning with the behavior described in the Servlet API. This is especially relevant when using null names and values in HTTP headers.

kotlinx.serialization JSON support

The org.jetbrains.kotlinx:kotlinx-serialization-json dependency is quite popular in the Kotlin ecosystem and is often transitive dependency. This caused issues where applications were using this library for reading/writing JSON instead of Jackson; there is no easy workaround. As of this version, the Kotlinx Serialization JSON codecs and converters will only be auto-detected and configured if the library is on the classpath and Jackson is not present.

GraalVM Native applications

Spring Framework 7.0 switches to the unified reachability metadata format, being adopted by the GraalVM community. Applications contributing RuntimeHints should apply the following changes:

The resource hints syntax has changed from a java.util.regex.Pattern format to a "glob pattern" format. In practice, applications might need to change their resource hints registrations if they were using wildcards. Previously, "/files/*.ext" matched both "/files/a.ext" and "/files/folder/b.txt". The new behavior matches only the former. To match both, you will need to use "/files/**/*.ext" instead. Registration of "excludes" has been removed completely.

Registering a reflection hint for a type now implies methods, constructors and fields introspection. As a result, ExecutableMode.INTROSPECT, and all MemberCategory values except MemberCategory.INVOKE_* are being deprecated. They have no replacement, as registering a type hint is enough.

In practice, it is enough to replace this:

hints.reflection().registerType(MyType.class, MemberCategory.DECLARED_FIELDS);

By this:

hints.reflection().registerType(MyType.class);

As for MemberCategory.PUBLIC_FIELDS and MemberCategory.DECLARED_FIELDS, values were replaced by INVOKE_PUBLIC_FIELDS and INVOKE_DECLARED_FIELDS to make their original intent clearer and align with the rest of the API. Note, if you were using those values for reflection only, you can safely remove those hints in favor of a simple type hint.

More details on the related changes in #33847.

New and Noteworthy

Null Safety

The Spring Framework codebase is annotated with JSpecify annotations to declare the nullness of APIs, fields and related type usages. JSpecify provides significant enhancements compared to the previous JSR 305 based arrangement, 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 vararg elements nullness. Using JSpecify annotations is also recommended for Spring-based applications. For more on this, check out the revisited "Null Safety" section of our reference documentation.

API versioning support in web applications

As of 7.0, server web applications can map version-specific routes to different controller methods by declaring a version range in @RequestMapping annotations. Versions can be resolved from multiple sources, like the request URL path, a header value, etc.

Web clients also support version when sending request to REST APIs.

This is work in progress, see the main issue tracking the API versioning theme.

Programmatic Bean Registration

Applications should never attempt to register several beans within a single @Bean method in a @Configuration class. Similarly, @Bean methods should declare the most concrete type as their return type. Those requirements often get in the way of more flexible bean registrations when more logic is required, or when multiple registration is needed.

This major version introduces a new programmatic bean registration mechanism with the BeanRegistrar contract that will help with those cases. See the new "Programmatic Bean Registration" section in the reference documentation.

`Optional` support with null-safe and Elvis operators in SpEL expressions

The java Optional type is now better supported in SpEL expressions. Not only can you now call null-safe operations on Optional types, but you can also use the Elvis operator to automatically unwrap an Optional.