SonarQube Java Analyzer : The Only Rule Engine You Need

If you have been following the releases of the Java plugin, you might have noticed that we work on two major areas for each release: we improve our semantic analysis of Java, and we provide a lot of new rules.

Another thing you might have noticed, thanks to the tag system introduced by the platform last year, is that we are delivering more and more rules tagged with “bug” and “security”. This is a trend we’ll try to strengthen on the Java plugin to provide users valuable rules that detect real problems in their code, and not just formatting or code convention issues.

What you might wonder then is: where do we get the inspiration for those rules?  Well, for starters, the SonarSource codebase is mostly written in Java, and most SonarSource developers are Java developers. So in analyzing our own codebase we find some patterns that we want to detect, turn those patterns into rules, and provide the rules to our users. But that is not enough, and that is why we are taking inspiration from other rule engines, and more specifically FindBugs. We are in the process of deprecating FindBugs rules by rewriting them using our technology.

Our goal is that at some point in 2015 we’ll stop shipping the FindBugs plugin by default with the platform (we’ll still support it and provide it through the update center) because out of the box, the Java Plugin will provide at least as much (hopefully more!) value as FindBugs.

This might seem pretentious, but there are a couple of reasons we are moving in this direction:

  • This is a move we already made with PMD and Checkstyle (and we are still supporting the sonar-pmd-plugin and sonar-checkstyle-plugin).
  • FindBugs works only at the bytecode level: the analysis only runs on compiled classes. The Sonar Java Plugin works with both sources and bytecode, and is thus able to be more precise in its analysis, eliminating false positives and detecting patterns that cannot be detected by FindBugs.
    For instance consider the following code run against the Java Plugin rule “Identical expressions should not be used on both side of a binary operator”, which deprecates multiple FindBugs rules:

    if(a == a) { //self comparison
    if( 2+1*12 == 2+1*12 ) { //selfcomparison

The approach used by FindBugs, which relies only bytecode, will not be able to detect the second issue because the second if will be erased by the compiler and thus will not be visible in bytecode.

  • FindBugs project activity: The activity on the project is quite low and thus the value coming out of it does not come fast enough to satisfy our users.
  • Documentation: One thing we really value at SonarSource, and that we think has made our products great, is that for each issue we raise we provide a clear explanation of why we raised the issue and an indication of how to fix it. This is something that FindBugs clearly lacks in our view, and we are confident we can offer better value in this area.

As we reimplement the FindBugs rules, our goal is also to remove some useless  or outdated rules, merge close-in-meaning rules, and report fewer false positives that FindBugs does.

However, this is going to take some work: we are still one step behind FindBugs regarding an essential part of what makes it valuable, the Control Flow Graph (CFG). Briefly: CFG allows tracking the value of a variable through the execution paths your code. An example of its use is to be able to detect NullPointerException without executing the code. This feature is not implemented yet in the SonarQube Java Plugin, but a first version was shipped in the latest version (3.3) of the C/C++ plugin. It’s in the roadmap of the Java plugin to embed this feature and deprecate the FindBugs rules requiring it.

This rewriting of FindBugs rules has already started, with a huge effort on documenting and specifying them properly. Out of the 423 rules provided by FindBugs we have decided to reimplement 394, and have already specified replacements for 286. At the time of this writing, 157 rules have already been reimplemented using our own technology (so about 40% of the implementable rules).

Don’t get me wrong: FindBugs is a great tool providing a lot of useful feedback to Java developers. But within the year, we will be at a point in the development of the SonarQube Java plugin where we can deliver even better feedback, and detect issues that even FindBugs can’t find.

© 2008-2016, SonarSource S.A, Switzerland. All content is copyright protected. SONARQUBE, SONARLINT and SONARSOURCE are
trademarks of SonarSource SA. All other trademarks and copyrights are the property of their respective owners. All rights are expressly reserved.