Skip to content

Conversation

@commonquail
Copy link
Contributor

Teach checks like MultipleNullnessAnnotations and RedundantNullCheck
to disregard annotations that look like nullness specification
annotations but that actually are not; namely the Jakarta Validation
@NotNull constraint.

Resolves: #4334

Teach checks like `MultipleNullnessAnnotations` and `RedundantNullCheck`
to disregard annotations that look like nullness specification
annotations but that actually are not; namely the Jakarta Validation
`@NotNull` constraint.

Resolves: google#4334
@commonquail
Copy link
Contributor Author

https://errorprone.info/bugpattern/RedundantNullCheck has the same limitation as #4334, but it's more disruptive because it happens at the call site instead of at the declaration site, and dangerous because the flagged null check is actually necessary. It would be swell to have some solution to that (and I'm probably looking at having to disable RedundantNullCheck otherwise).

There are a few other constraint annotations that match "null" but I believe none of those are an issue. Unfortunately I'm not aware of any other offenders either, so the case is not very strong.

<artifactId>jakarta.validation-api</artifactId>
<version>3.1.0</version>
<scope>test</scope>
</dependency>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like the test framework can create additional files on the side. That could probably be used to simulate the names as an alternative to pulling in a dependency.


public static ImmutableList<AnnotationTree> annotationsRelevantToNullness(
List<? extends AnnotationTree> annotations) {
// Missing support for FALSE_NULLNESS_ANNOTATIONS
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what to do about this or how much it matters. There are test cases that hit this method but none that hit the MemberSelectTree inside simpleName(AnnotationTree). I can get a qualified name from a MemberSelectTree but I don't see how that can be accomplished for an IdentifierTree.

Copy link
Contributor Author

@commonquail commonquail Dec 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That must be what Matchers::isType is for. This looks like it could work:

  private static final Matcher<AnnotationTree> NOT_FALSE_NULLNESS_ANNOT =
      Matchers.not(
          Matchers.anyOf(FALSE_NULLNESS_ANNOTATIONS.stream().map(Matchers::isType).toList()));

  public static ImmutableList<AnnotationTree> annotationsRelevantToNullness(
      List<? extends AnnotationTree> annotations, final VisitorState state) {
    return annotations.stream()
        .filter(a -> NOT_FALSE_NULLNESS_ANNOT.matches(a, state))
        .filter(a -> ANNOTATION_RELEVANT_TO_NULLNESS.test(simpleName(a)))
        .collect(toImmutableList());
  }

but requires passing VisitorState to (one) annotationsRelevantToNullness.

For your consideration: commonquail@67be368

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MultipleNullnessAnnotations shouldn't consider Validation Annotations

1 participant