FindBugs 1.2 demo and results

If you just want to try running FindBugs against your own code, you can run FindBugs using Java Webstart. This will use our new gui under Java 1.5+ and our old gui under Java 1.4. The new gui provides a number of new features, but requires Java 1.5+. Both use exactly the same analysis engine.

This web page provides results of running FindBugs 1.2.0 against several open source applications. We provide a summary of the number of bugs we found, as well as a generated HTML listing of the bugs and a Java WebStart demo of the new GUI we've introduced in FindBugs version 1.1, displaying the warnings and the relevant source.

The applications and versions of them we report on are somewhat arbitrary. In some cases, they are release versions, in other cases nightly builds. We find lots of bugs in every large code base we examine; these applications are certainly not the worst we have seen. I have been allowed to confidentially examine the results of running FindBugs against several closed commercial code bases by well respected companies; the results I've seen there are not significantly different from what I've observed in open source code bases.

Experimental details: These results are from running FindBugs 1.2.0 at standard effort level. Our results do not include any low priority warnings or any warnings about vulnerabilities to malicious code. Although we have (repeatedly) manually audited the results, we haven't manually filtered out false positives from these warnings, so that you can get a feeling for the quality of the warnings generated by FindBugs.

Some of the bugs contain audit comments: they are marked as to whether we thought the warning indicated a bug that should or must be fixed, or whether it was not, in fact, a bug.

In the webstart versions, we've only included the bugs for which we were able to identify source files. The number of lines of non-commenting source statements in the table below (KNCSS) is derived from the same files that we analyzed and in which we report bugs; we actually compute KNCSS from the classfiles, not the source files.

Vulnerability disclosure: Thankfully, Java isn't C or C++. Dereferencing a null pointer or accessing outside the bounds of an array generates a runtime exception rather than a shell exploit. We do not believe that any of the warnings here represents a security vulnerability, although we have not audited them to verify that. These projects are all aware of the existence of FindBugs, and FindBugs is already open source and available for use both by developers and attackers, we don't believe that making these results available constitutes a reckless disclosure.

Recommendations: First, review the correctness warnings. We feel confident that developers would want to fix most of the high and medium priority correctness warnings we report. Once you've reviewed those, you might want to look at some of the other categories.

In other categories, such as Bad practice and Dodgy code, we accept more false positives. You might decide that a pattern bug pattern isn't relevant for your code base (e.g., you never use Serialization for persistent storage, so you never care about the fact that you didn't define a serializationUID), and even for the bug patterns relevant to your code base, perhaps only a minority will reflect problems serious enough to convince you to change your code.

Please be patient The Web start versions not only have to download the applications, they need to download about 10 megabytes of data and source files. Please be patient. Sorry we don't have a progress bar for the data and source download; the ability to remotely download a data and source archive is a little bit of a hack. We've provided small versions of some of the data sets that include only the correctness bugs and the source files containing those warnings. The small datasets are about a quarter of the sizes of the full datasets.

KNCSS - Thousands of lines of non-commenting source statements

Bug categories

Correctness bug

Probable bug - an apparent coding mistake resulting in code that was probably not what the developer intended. We strive for a low false positive rate.

Bad Practice

Violations of recommended and essential coding practice. Examples include hash code and equals problems, cloneable idiom, dropped exceptions, serializable problems, and misuse of finalize. We strive to make this analysis accurate, although some groups may not care about some of the bad practices.

Dodgy

Code that is confusing, anomalous, or written in a way that leads itself to errors. Examples include dead local stores, switch fall through, unconfirmed casts, and redundant null check of value known to be null. More false positives accepted. In previous versions of FindBugs, this category was known as Style.

Send comments to findbugs@cs.umd.edu