javabugs:S6555 false positive after checking for null

Rules and Languages Report False-positive / False-negative...
1
  • Language: Java
  • Rule: [javabugs:S6555] Null pointers should not be dereferenced
  • SonarQube environment:
    • SonarQube Server: v2025.2 (105476)
    • SonarQube for IDE: 10.24.0.81420 for IntelliJ

The rule triggers in this example, despite the use of Spring’s @NonNullApi at package level.

class SonarExample {
  public void triggerFalsePositive(
      // 1: Parameter ourObject is received
      OurClass ourObject
  ) {
    // 2: 'otherMethod' is called
    // 3: Value is passed as parameter ourObject
    otherMethod(ourObject);
    // 7: The access on a value that can be null
    // FALSE POSITIVE TRIGGERS HERE
    ourObject.doSomething();
  }

  private void otherMethod(
      // 4: Parameter ourObject is received
      OurClass ourObject
  ) {
    // 6: Taking true branch
    if (
        // 5: Assuming 'ourObject' is null
        ourObject == null
    ) {
      // Just checking for null is enough to trigger the sonar violation
    }
  }

  static class OurClass {
    void doSomething() {
      // Do something useful
    }
  }
}

Interestingly (to me, at least!) SonarQube is obviously aware that ourObject cannot be null, because this example also triggers [java:S2583] Conditionally executed code should be reachable:

  private void otherMethod(
      // 1: Implies 'ourObject' can not be null.
      OurClass ourObject
  ) {
    if (
        // 2: Expression is always false.
        ourObject == null
    ) {

I believe this example is different to the one in javabugs:S6555 gets confused by passing NonNull argument to Nullable function. But feel free to close this as a duplicate, if you believe the underlying issue is the same.

4

Hello Chris,

Thanks for reporting. You’re right that this is an FP.

There are 2 causes; (1) the analyzer does not take into account the @NonNullApi, and (2) it uses the if-statement to assume that ourObject can be null. The issue raised for S2583 is handled by a different analyzer, which is aware of the annotation (if you look at the repository for these rules, you’ll see that S6555 is in the repository javabugs and S2583 in the repository java).

We have put a significant amount of efforts to avoid such FPs in the last few months, by eliminating cause (2). On the latest version of the analyzer, we do not raise an issue on your example anymore.

We also added support for nullability annotations, although only for those marking parameters that are potentially null. I’m opening a ticket to also support annotations explicitly ruling out null.

A version of the analyzer fixing this issue is live on SonarQube Cloud, but unfortunately it has not yet been packaged with a SonarQube Server release. We’ll make sure to inform you as soon as it is available.

Again, many thanks for the detailed report. It is really appreciated.

Cheers,
Sylvain