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

The Spring Framework codebase has been updated 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 and Kotlin integration and the capability to specify generic type, array and varargs element null-safety.

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 the use of types. For more on this, check out the revisited "Null Safety" section of our reference documentation.

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.