SonarJava does support interprocedural analysis?(NPE)

Rules and Languages Report False-positive / False-negative...
1 
A.java <- class A { static String foo() { return null;}}
B.java <- class B { String bar(){ A.foo().xxx();}}

Here B.java, A.foo() returns null, it should raise NPE, but the sonarJava doesn’t report this problem…
Does sonarJava support cross-file (interprocedural analysi)?

2

Short answer is : no.

Longer answer is : we have some behaviors of well known methods that are read into bytecode and avalaible for such kind of rules. So yes for a very limited scope as of today.
We do have in mind do develop some technologies and tools in order to detect such cases but this is way to early to commit to anything yet…

3

What you describe is using this: BehaviorCache? So If the user could provide sonar.java.binaries, sonarjava can get the information to reduce the false positive?

4

Hello,

BehaviorCache is only the tip of the iceberg. It allows computation (and then store) summaries of well known methods from common utility libraries (white-list based). For these methods, we know the engine is able to deduce the correct behaviors, which won’t produce FPs during analysis.

The interprocedural cross-file analysis capacities of the SonarJava engine currently stops at this point. For methods defined in the same file, however, the engine will try as much as possible to take benefit of inter-procedural analysis, and the deduced behaviors. Concretely, the following case would have been detected:

A.java

class A {
  static String foo() {
    return null;
  }

  void bar(){
    foo().length(); // NPE detected
  }
}

Hope this helps,
Michael

5

Looks great, I try the above example. It does work. Why couldn’t we support inter-procedural analysis? AFAIK, like Infer/Coverity, they can support this. Here bcoz of our current resource is not satisfied or the product-self’s balance choice(the analysis speed is much more important)

6

Hello,

There are many reasons why we have not been able to escalate our approach to cross-file analysis, while it works in practice between methods of the same file already.

Some reasons are tied to performance (both in memory and in time), and some are related to the extremely high False Positive rate (FP) we were getting out of it, due to approximations of the engine cascading from files to files when something wrong was happening.

Ultimately, these made users perceives the rules relying on this approach as being much less valuable, especially when having to fight with frustration against many FPs before getting a single True Positive (TP).

This thread being two years old, I’ll let you open a new topic having any feedback to do on the topic.

Cheers,
Michael