The Developer Ecology - Java: The Good Parts - page 188

FindBugs
We've written our code. We've written a lot of tests for that code. If we are developing as part
of a team, [ 50 ] we've had at least one other member of the team review the code and the tests,
which has led to some changes in both the code and the tests. Having gone through all that,
we can be sure that our code is bug-free, right?
Unfortunately, no. No matter how careful we are, there is always some bug that has made it
through our scrutiny, slipped by the tests, and gone unnoticed by our reviewers. So we should
be on the lookout for any tool that attempts to help us find the bugs that might otherwise get
away.
One of the more interesting of such tools is FindBugs, [ 51 ] developed at the University of Mary-
land by a group originally led by Bill Pugh and David Hovemeyer. The idea behind the pro-
ject is that certain patterns in code are likely to indicate a bug in the code. FindBugs is a pro-
gram that does static analysis looking for such patterns and reports the results back to the user.
FindBugs is not a style checker; the code that it looks at is the binary output of your source. It
operates on Java bytecodes, finding the likely bug patterns in that representation.
I tend to think of FindBugs as the Java-age equivalent of the old C lint program. Back in the
day, you would run your C code through lint to find all of the problems that the compiler
would happily ignore, such as casting a structure from one type to another. Sometimes lint
would report problems that weren't really there; after all, there were times when you did want
to cast from one type to another. But it was worth taking a look if lint reported something
problematic to make sure that you really wanted to do what it was reporting as fishy.
In the same way, FindBugs will do a static analysis of your Java code and report places where
there might be a bug. When FindBugs reports a problem, what it is doing is reporting a pos-
sible problem; it doesn't know that the code in question is wrong, but it relies on the know-
ledge that patterns like this code are often the cause of a problem. Just as lint would some-
times warn you against doing something that in fact you meant to do, running FindBugs will
result in some false-positive reports. The developers of FindBugs try to minimize the number
of false-positives, but they are working in a realm that is not well understood, and so have to
rely on heuristics and statistical experience for their indicators. The Java language and com-
piler already do a reasonable job of eliminating problems that are certain to produce bugs,
such as memory problems or illegal type casts. FindBugs moves to a new frontier, attempting
to detect likely bugs.
I like to run FindBugs fairly late in the development cycle, after the tests have been success-
fully run and another engineer has reviewed the code. It is a final check on the code, allowing