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
The Jakarta (formerly JavaX) Validation spec shouldn't be considered for this bug. My rationale is that it is a runtime validation which may not occur until late in a process.
This is not, perhaps the best example of code, but it's what my brain is currently coming up with.
publicclassFoo {
@NotNull@NullableLonggetId();
}
if ( foo.getId() == null ) {
foo.set(1L); // yes this is terrible, but you could query a database sequence, or this could be a UUID
}
repository.save(foo); // if I remove the above if statement, and a null is passed this would throw an error
so, getId is validly nullable at runtime, but at the point of validation we want it to be non null.
note: you could ignore the javax/jakarta namespaced annotations explicitly, but as far as I'm aware NotNull is always the name of the runtime checks, and some case insensitive variant of NonNull is the "compile time" variant
perhaps this is the whole point of this check though, it's docs are somewhat lacking; and if this is the point, perhaps they could be improved.
The text was updated successfully, but these errors were encountered:
Thanks for the report. The use-case for MultipleNullnessAnnotations is primarily nullness annotations that have semantics similar to the https://github.com/jspecify/jspecify ones. We could look at having the check skip annotations with incompatible semantics, or clarifying what the use-case for it is.
Yes, thanks. I'm largely clueless about the validation annotations, which I have probably seen as many times in the past couple weeks as I had in my life previously.
We have at least one list of nullness annotations, which sadly includes at least one notably "@NotNull" annotation that is "similar to JSpecify" more than "similar to Jakarta Validation," org.jetbrains.annotations.NotNull. That doesn't make this proposal impossible to implement, but it keeps it from being a one-liner. For now, you might want to set -Xep:MultipleNullnessAnnotations:OFF.
Ugh, thanks jetbrains. Fortunately you can probably just use the two official validation spec paths for that. I don't know if I would bother going and tracking down other vendor specific ones. Like I'm sure hibernate had one at some point.
The Jakarta (formerly JavaX) Validation spec shouldn't be considered for this bug. My rationale is that it is a runtime validation which may not occur until late in a process.
This is not, perhaps the best example of code, but it's what my brain is currently coming up with.
so, getId is validly nullable at runtime, but at the point of validation we want it to be non null.
note: you could ignore the javax/jakarta namespaced annotations explicitly, but as far as I'm aware
NotNull
is always the name of the runtime checks, and some case insensitive variant ofNonNull
is the "compile time" variantperhaps this is the whole point of this check though, it's docs are somewhat lacking; and if this is the point, perhaps they could be improved.
The text was updated successfully, but these errors were encountered: