Gregg Sporar's Blog

Talking About Static Analysis

We are fortunate that in the Java world, there are many high-quality static analysis tools available for free. I talked about a few of them the other night at a meeting of the Austin Java Users Group.

Like many people, the first static analysis tool for Java code that I encountered was FindBugs. The current version is 1.1.1, but do not let that relatively low version number fool you - the tool is very robust and has been around for quite a while.

My current fascination with static analysis tools is driven by two things: Project Jackpot and a desire to spread the word about static analysis tools. Based on my very un-scientific research, there are still many developers who use Java but do not know about these tools.

In September I went to Oslo for JavaZone. I was talking with a gentleman who attended my presentation and our converation drifted to tools for verifying the correctness of multi-threaded code. I asked if he was using FindBugs (which has many bug detectors for common concurrency problems) and he replied that he had never heard of it. I was surprised for two reasons: he indicated he was not new to the Java world and he apparently keeps up with what is going on - he was attending a conference for Java developers.

My presentation in Austin provided further evidence. As I described each tool I asked for a show of hands for the number of people who had heard of the tool. Not many hands went up.

One more data point: Fabiano Cruz recently wrote an excellent blog entry on static analysis tools. I sent him an email and he and I have corresponded a bit since then. He stated that many of the developers he encounters have also not heard of these tools.

So what's so great about these tools anyway? They help find bugs. When talking about static analysis, "bug" is defined very broadly. In other words, static analysis tools help locate common anti-patterns. Examples include failure to adhere to coding standard and unsafe practices such as calling overridable methods from a constructor.

I only had a twenty minute speaking slot, so I had to move quickly in order to demo six tools: FindBugs, Checkstyle, PMD, IntelliJ IDEA's Inspections feature, the Eclipse Testing and Performance Tools Platform's static analyis sub-project, and the NetBeans IDE's Project Jackpot.

To me there are three very interesting trends in the world of Java static analysis tools. The first is the increasing use of the technology inside the major Java IDEs. IntelliJ IDEA's Inspections feature has been available for a while, but the Eclipse TPTP project and Project Jackpot have only been made available relatively recently. The second is a follow-on of the first: the IDE-based tools can not only find problems in your code, in many cases they can automatically change the code for you in order to fix the problem. I do not know of a standalone static analysis tool that offers that feature.

The third trend is that it is getting easier and easier to define your own "bug." In other words, if a tool does not provide a pre-built definition for a particular code pattern that you are interested in, you can write your own. If that means writing to a Java API, most folks are not interested. More and more though, this is not necessary. PMD has a feature where XPath expressions can be used. Eclipse TPTP has a few simple templates available that you can choose from a dialog box. And Project Jackpot has a very nice rules language that provides a unique feature: you can not only specify a pattern to find, but also a pattern to be used to replace any code that is found.

My presentation was not intended as a contest. All of these tools have strengths and weaknesses. But I did put up a comparison matrix, which is below.

The world of static analysis tools is much bigger than this. I have only discussed bug-finding tools. There are others that are geared more towards helping you understand the architecture of your source code. Fabiano and I are planning to submit a proposal for a Birds of a Feather talk on static analysis tools for JavaOne 2007.

Comments

• Great post, Gregg! I didn't know most of these tools.

  Posted by: christian_schlichtherle on November 09, 2006 at 08:03 AM

• IntelliJ has "Structural Search Inspections", based on the built-in AST-based SSR ("Structural Search & Replace") Rule language.

  You can write a matching rule, and a replacing rule, and configure those to be used by an inspection. So it's like Jackpot, but with a nice UI.

  Posted by: plethora on November 09, 2006 at 08:10 AM

• While IDEA itself is not free, it is worth perhaps an asterisk to note that most of the code inspection functionality of IDEA is both free and open-source.

  Posted by: dgriffit on November 09, 2006 at 08:26 AM

• FindBugs has a plugin interface. It can be used to add own, other detectors quite simple, e.g. fb-contrib.sf.net. It has a pluggable backend, so that detectors can use asm, or becel.

  Posted by: sven on November 09, 2006 at 09:50 AM

• Hi sven. Can you post a link to information about the pluggable backend for FindBugs? I was not able to find it on their web site. Thanks.

  Posted by: gsporar on November 09, 2006 at 11:23 AM

• Hi plethora. Thanks for pointing out the "Structural Search Inspections" feature in IntelliJ IDEA, I did not realize it was there. It looks like the ability to use those sorts of inspections is new in 6.0.

  Posted by: gsporar on November 09, 2006 at 11:36 AM

• One tool that's missing in this comparison is Lint4j, which has been around for more than three years. It analyzes Java source code, is free, and has Ant and Eclipse integration.

  Posted by: sreich on November 09, 2006 at 12:05 PM

• You should probably add Oralce JDeveloper's Audit framework to your table.
  Entries are Free, Examined Source, Scriptable, Automatically Apply Fixes, Java API.
  

  Posted by: gevatron on November 10, 2006 at 02:41 PM

• See also fb-crasher (http://code.google.com/p/fb-crasher/) which takes the theoretical bugs found by FindBugs and turns them into unit tests, and then checks if the unit test passes or fails.
  If the unit test fails it's found a real bug, and you can fix it and add the unit test to your regression pack.

  Posted by: diroussel on November 10, 2006 at 03:28 PM

• And also: Spoon, which provides an Eclipse plugin to package and deploy your own validators and quick fixes into Eclipse (or any container that would support the same format - only the plugin is Eclipse dependant). Packaged validators are called Spoonlets, and they can be seen as compilation components that extend the Java semantics. It's free too.

  Posted by: renaudpawlak on November 17, 2006 at 08:44 AM

• You might be interested about NDepend.

  NDepend analyses source code and .NET assemblies. It allows controlling the complexity, the internal dependencies and the quality of .NET code. .

  NDepend provides a language (CQL Code Query Language) dedicated to query and constraint a codebase. .

  It also comes from with advanced code visualization (Dependencies Matrix, Metric treemap, Box and Arrows graph...), more than 60 metrics, facilities to generate reports and to be integrated with mainstream build technologies and development tools. .

  NDepend also allows to compare precisely different versions of your codebase..

  A Java version is under development.
  

  Posted by: patricksmacchia on May 03, 2007 at 03:01 AM

This work is licensed under a Creative Commons License.