False-Positive: reports javabugs:S2259 on object that can't be null

  • Language: Java 25
  • Rule: javabugs:S2259 - A NULL object should not be accessed
  • Version: SonarQube Server, Developer Edition, v2026.5 (132435)
    • Cannot reproduce with SonarQube for IDE
  • Why is it a False-Positive: Because from looking at the code, the object cannot be null. Additionally, other tools don’t report it as an error nor did SQ report it in the past either.

Hello, similar to False positive javabugs:S2259 — null checks performed by methods from external libraries are ignored , but instead of the method originating from an external library, it originates from the same project.

public class MyClass1 {
    private Object object;
    public final Object getLazyObject() {
        if (object == null) {
            object = new Object();
        }
        return object;
    }
}
public class MyClass2 {
    private final MyClass1 class1;

    public MyClass2(final MyClass1 class1) {
        this.class1 = class1;
    }

    static void main() {
        new MyClass2(new MyClass1()).test();
    }

    private void test() {
        final String string = class1.getLazyObject().toString(); // reports: javabugs:S2259 - Fix this access that will throw a NullPointerException when executed.
        System.out.println(string);
    }
}

I will try to trim the example down even further. I will edit/post updates if I reproduce it with a more trimmed down version.

could be a duplicate of: Jira

Hey @blazkosi, welcome to the Community!

I agree with you that this looks like a false positive. To me, it doesn’t seem to be covered by any existing ticket:

  • The SONARJAVA-5361 ticket that you found doesn’t apply here because that one is for the java:S2259 implementation of the rule. You are encountering this FP on javabugs:S2259, which is a different implementation (in principle, a more powerful one!).
  • The other Community thread you found is indeed for the javabugs implementation, and a (private) ticket has been created out of it. However, it seems to cover only the case where the null check happens in library code. In your case, it happens in project code, so it seems different: the null check is explicitly implemented so our analysis logic should take it into account.

I’m going to flag this for the devs, they might need to create a new ticket.

Hi @blazkosi :slight_smile:

Thank you for the reproducer and the screenshots! I can confirm this is an FP and it is present in the current version of the analyzer.

It is not covered by existing tickets and I created a ticket to track it.

Best regards,

Anton