Skip to content

Commit ef06bf4

Browse files
committed
Refine null-safety migration documentation
See gh-28797
1 parent 6d2d10c commit ef06bf4

File tree

1 file changed

+6
-2
lines changed

1 file changed

+6
-2
lines changed

framework-docs/modules/ROOT/pages/core/null-safety.adoc

+6-2
Original file line numberDiff line numberDiff line change
@@ -110,8 +110,12 @@ annotation in the `org.springframework.lang` package can be used to specify that
110110
Spring null-safety annotations {spring-framework-api}/lang/Nullable.html[`@Nullable`],
111111
{spring-framework-api}/lang/NonNull.html[`@NonNull`],
112112
{spring-framework-api}/lang/NonNullApi.html[`@NonNullApi`], and
113-
{spring-framework-api}/lang/NonNullFields.html[`@NonNullFields`] in the `org.springframework.lang` package are
114-
deprecated as of Spring Framework 7 and superseded by JSpecify annotations.
113+
{spring-framework-api}/lang/NonNullFields.html[`@NonNullFields`] in the `org.springframework.lang` package have been
114+
introduced in Spring Framework 5 when JSpecify did not exist and the best option was to leverage JSR 305 (a dormant
115+
but widespread JSR) meta-annotations. They are deprecated as of Spring Framework 7 in favor of
116+
https://jspecify.dev/docs/start-here/[JSpecify] annotations, which provide significant enhancements such as properly
117+
defined specifications, a canonical dependency with no split-package issue, better tooling, better Kotlin integration
118+
and the capability to specify the nullability more precisely for more use cases.
115119

116120
A key difference is that Spring null-safety annotations, following JSR 305 semantics, apply to fields,
117121
parameters and return values while JSpecify annotations apply to type usages. This subtle difference

0 commit comments

Comments
 (0)