While analyzing Java code using SonarQube, I found that it does not accurately report null pointer dereferences in non-static methods. The following examples illustrate the issue:
Example 1: (Issue reported by S2259)
public class NullPointerDereference {
public static void hasArguments(String name) {
int length = name.length(); // report S2259, NullPointerException
System.out.println("Name length: " + length);
}
public static void main(String[] args) {
String name = null;
hasArguments(name);
}
}
Example 2: (Issue not reported by S2259)
public class NullPointerDereference {
public void hasArguments(String name) {
int length = name.length(); // FN
System.out.println("Name length: " + length);
}
public static void main(String[] args) {
String name = null;
NullPointerDereference nullPointer = new NullPointerDereference();
nullPointer.hasArguments(name);
}
}
In the first example, SonarQube correctly identifies the null pointer dereference in the static method, whereas in the second example, it fails to report the same issue when the method is non-static. This inconsistency in handling S2259 between static and non-static methods should be addressed to ensure accurate analysis of potential null pointer dereferences.
First, thank you for your patience. I should have answered earlier.
What you are reporting is indeed an FN of the rule, however, this is an intended one. The FN is caused by a limitation of the Symbolic Execution engine rule java:S2259 rely on. Thanks for pointing us to it. Unfortunately, we don’t plan to fix it for the time being, as it would require too much investment.
More precisely, in your second example, the method hasArguments() is a class instance method and therefore requires a class instance to be called. Unfortunately, so far the engine that runs this rule is not able to track runtime types in the execution paths it follows. In order to explore what a method is doing, and to be as much as possible sure to not raise FPs, the engine will therefore only track methods that are effectively final.
In your example, since the method can be overridden (even if it is not in your scenario), then the engine does not take the risk to raise an FP and doesn’t raise an issue. Make your class final, or your method static, or final, and you will see the issue appear. In such context, it is necessarily this method being called, and so the engine knows it does not do any mistake.