Some practical usage to findbugs

; Date: Mon Nov 14 2005

Tags: Java

A few months ago I posted some initial impressions on (web.archive.org) Find Bugs. Since then my backburner task has been to study how to use the tool with the tools developed by the Java Quality Team.

The Java Quality team has several tools (harnesses, test frameworks, etc) to aid the work we do. I've discussed bits about them before, so I won't go into that again. Suffice to say the managers were impressed by Bill Pugh's demonstration when he visited us last summer and they're interested in seeing it or similar tools used in developing those tools. We are of course wanting to have our tools be robust etc so that the team can focus on their real job, finding bugs in Java, rather than fighting with flaky tools.

The simplest use is to simply run findbugs on your current build, and use the GUI to browse through the results. The GUI is fairly nice and that's easy enough to do.

In addition to the GUI there are several shell scripts in the distribution. Unfortunately they aren't well documented, with the only clue to the function often being the USAGE message and the source code.

Suppose you want to see how you're doing over time?

For example in Bill Pugh's demo, what probably caught the eye of the managers was his graph of infinite loops in the JDK. He's been tracking the bugs in the JDK over a long period of time. The chart he showed was the number of infinite loops in each JDK build, which was rather eye-opening to see. The problem is that the findbugs distribution doesn't include a method to generate those charts.

I just worked out a method to generate the chart.

First, you run the findbugs tool on several builds of your application. For each, you save the bugs found into a file. The file format is XML of a somewhat obvious format, which isn't important at the moment.

Next you run the "countBugs" script once for each set of bugs you saved previously. This script counts the number of bugs for each classification, giving you a simple text output.

Last you manually construct a spreadsheet. I found it easiest to use rows for the bug classification, and columns for the build number. I used the Star Office graphing facility and made some pretty nice graphs. To graph the counts for a specific bug type I'd select the row for the bug type, and select the first row which has the build names as column headers. Then select the INSERT/CHART menu, and click through the wizard, make sure to select labels from both the first row and first column.

There are more scripts but it isn't entirely clear how to make good use of them.

For example "aliasedWarnings" seems to find duplicate bugs, but it isn't clear what the matching criteria is.

And "updateBugs" appears to merge a set of results gathered over time, but it isn't clear what you can do with the resulting file.

Source: (web.archive.org) weblogs.java.net

Comments

Hi David - You might be interested in PMD's duplicate code detector. It, well, finds duplicate code :-) It uses Karp-Rabin string matching and is quite snappy. It also plugs into a few IDEs.

Cheers,

Tom Copeland

Posted by: tcopeland on November 15, 2005 at 07:49 PM

About the Author(s)

(davidherron.com) David Herron : David Herron is a writer and software engineer focusing on the wise use of technology. He is especially interested in clean energy technologies like solar power, wind power, and electric cars. David worked for nearly 30 years in Silicon Valley on software ranging from electronic mail systems, to video streaming, to the Java programming language, and has published several books on Node.js programming and electric vehicles.