@@ -119,6 +119,14 @@ A good example of `@Contract` benefits is
119
119
with `@Contract("null, _ -> fail")`. With the configuration above, NullAway will understand that after a successful
120
120
invocation, the value passed as a parameter is not null.
121
121
122
+ Optionally, it is possible to set `NullAway:JSpecifyMode=true` to enable
123
+ https://github.com/uber/NullAway/wiki/JSpecify-Support[checks on the full JSpecify semantics], including annotations on
124
+ generic types. Be aware that this mode is
125
+ https://github.com/uber/NullAway/issues?q=is%3Aissue+is%3Aopen+label%3Ajspecify[still under development] and requires
126
+ using JDK 22 or later (typically combined with the `--release` Java compiler flag to configure the
127
+ expected baseline). It is recommended to enable the JSpecify mode only as a second step, after making sure the codebase
128
+ generates no warning with the recommended configuration mentioned above.
129
+
122
130
=== Warnings suppression
123
131
124
132
There are a few valid use cases where NullAway will wrongly detect nullness problems. In such case, it is recommended
@@ -135,6 +143,8 @@ outside of a lambda for the code path within the lambda.
135
143
non-null values even if that can't be expressed by the API.
136
144
- `@SuppressWarnings("NullAway") // Well-known map keys` can be used when `Map#get` invocations are done with keys known
137
145
to be present and non-null related values inserted previously.
146
+ - `@SuppressWarnings("NullAway") // Overridden method does not define nullness` can be used when the super class does
147
+ not define nullness (typically when the super class is coming from a dependency).
138
148
139
149
140
150
[[null-safety-migrating]]
0 commit comments