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.
public class Foo {
@NotNull
@Nullable
Long getId();
} 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 errorso, 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 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
NotNullis always the name of the runtime checks, and some case insensitive variant ofNonNullis 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.