You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use Spring's Nullness utility to determine JSpecify nullness.
We now use Nullness.forMethodParameter(…) to introspect method return types and argument types for nullness in addition to Spring's NonNullApi and JSR-305 annotations.
Closes#3100
Copy file name to clipboardExpand all lines: src/main/antora/modules/ROOT/pages/repositories/null-handling.adoc
+70-1
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
[[repositories.nullability]]
2
2
= Null Handling of Repository Methods
3
3
4
-
As of Spring Data 2.0, repository CRUD methods that return an individual aggregate instance use Java 8's `Optional` to indicate the potential absence of a value.
4
+
Repository CRUD methods that return an individual aggregate instances can use `Optional` to indicate the potential absence of a value.
5
5
Besides that, Spring Data supports returning the following wrapper types on query methods:
6
6
7
7
* `com.google.common.base.Optional`
@@ -16,7 +16,74 @@ See "`xref:repositories/query-return-types-reference.adoc[Repository query retur
16
16
[[repositories.nullability.annotations]]
17
17
== Nullability Annotations
18
18
19
+
=== JSpecify
20
+
21
+
As on Spring Framework 7 and Spring Data 4, you can express nullability constraints for repository methods by using https://jspecify.dev/docs/start-here/[JSpecify].
22
+
JSpecify is well integrated into IntelliJ and Eclipse to provide a tooling-friendly approach and opt-in `null` checks during runtime, as follows:
23
+
24
+
* https://jspecify.dev/docs/api/org/jspecify/annotations/NullMarked.html[`@NullMarked`]: Used on the module-, package- and class-level to declare that the default behavior for parameters and return values is, respectively, neither to accept nor to produce `null` values.
25
+
* https://jspecify.dev/docs/api/org/jspecify/annotations/NonNull.html[`@NonNull`]: Used on a type level for parameter or return values that must not be `null` (not needed value where `@NullMarked` applies).
26
+
* https://jspecify.dev/docs/api/org/jspecify/annotations/Nullable.html[`@Nullable`]: Used on the type level for parameter or return values that can be `null`.
27
+
* https://jspecify.dev/docs/api/org/jspecify/annotations/NullUnmarked.html[`@NullUnmarked`]: Used on the package-, class-, and method-level to roll back nullness declaration and opt-out from a previous `@NullMarked`.
28
+
Nullness changes to unspecified in such a case.
29
+
30
+
.`@NullMarked` at the package level via a `package-info.java` file
It is recommended that this annotation is specified just before the related type.
42
+
43
+
For example, for a field:
44
+
45
+
[source,java,subs="verbatim,quotes"]
46
+
----
47
+
private @Nullable String fileEncoding;
48
+
----
49
+
50
+
Or for method parameters and return value:
51
+
52
+
[source,java,subs="verbatim,quotes"]
53
+
----
54
+
public static @Nullable String buildMessage(@Nullable String message,
55
+
@Nullable Throwable cause) {
56
+
// ...
57
+
}
58
+
----
59
+
60
+
When overriding a method, nullness annotations are not inherited from the superclass method.
61
+
That means those nullness annotations should be repeated if you just want to override the implementation and keep the same API nullness.
62
+
63
+
With arrays and varargs, you need to be able to differentiate the nullness of the elements from the nullness of the array itself.
64
+
Pay attention to the syntax
65
+
https://docs.oracle.com/javase/specs/jls/se17/html/jls-9.html#jls-9.7.4[defined by the Java specification] which may be initially surprising:
66
+
67
+
- `@Nullable Object[] array` means individual elements can be null but the array itself can't.
68
+
- `Object @Nullable [] array` means individual elements can't be null but the array itself can.
69
+
- `@Nullable Object @Nullable [] array` means both individual elements and the array can be null.
70
+
71
+
The Java specifications also enforces that annotations defined with `@Target(ElementType.TYPE_USE)` like JSpecify
72
+
`@Nullable` should be specified after the last `.` with inner or fully qualified types:
73
+
74
+
- `Cache.@Nullable ValueWrapper`
75
+
- `jakarta.validation.@Nullable Validator`
76
+
77
+
https://jspecify.dev/docs/api/org/jspecify/annotations/NonNull.html[`@NonNull`] and
78
+
https://jspecify.dev/docs/api/org/jspecify/annotations/NullUnmarked.html[`@NullUnmarked`] should rarely be needed for typical use cases.
79
+
80
+
=== Spring Framework Nullability and JSR-305 Annotations
81
+
19
82
You can express nullability constraints for repository methods by using {spring-framework-docs}/core/null-safety.html[Spring Framework's nullability annotations].
83
+
84
+
NOTE: As on Spring Framework 7, Spring's nullability annotations are deprecated in favor of JSpecify.
85
+
Consult the framework documentation on {spring-framework-docs}/core/null-safety.html[Migrating from Spring null-safety annotations to JSpecify] for more information.
86
+
20
87
They provide a tooling-friendly approach and opt-in `null` checks during runtime, as follows:
21
88
22
89
* {spring-framework-javadoc}/org/springframework/lang/NonNullApi.html[`@NonNullApi`]: Used on the package level to declare that the default behavior for parameters and return values is, respectively, neither to accept nor to produce `null` values.
0 commit comments