me to find and look at those parts of my program that might be problematic. At that point, I'm
willing to deal with some false-positives, since finding even one or two genuine bugs is a big
win. It might be that the real value of FindBugs is in the stimulus it gives for a final look at
the code, although there are times when looking at the places it reports has given me a real
The other thing that I like about FindBugs is that it started its life as an academic project, so
there are papers explaining the approach and the ideas underlying this kind of bug detection.
Knowing why some decisions are made is an important part of building trust in a tool like
this. Of course, the project is also open source, so one can always look at the source to find
out what is really going on. But I find the papers a more manageable way of understanding
the basic ideas, and so appreciate having both.
The tools discussed in this chapter are exemplars of a more general trend. Surrounding the
Java language, there is an increasingly diverse and rich set of tools for the development of
software. Open source communities, either sponsored by a company (or set of companies) or
coming out of academia, do much of the development for this ecology of software tools. The
quality can be variable, but is generally quite good. Support happens via email or in public
forums, which makes some companies nervous, but which in my experience is far superior to
the kinds of paid-for support that you get with more standard commercial offerings.
There is a particular theme to the tools we have looked at in this chapter, having to do with
the software cycle of writing code, testing that code, and eliminating bugs in the code. There
are additional tools that go further into this cycle. For example, Checkstyle [ 52 ] is a tool that
will automate the checking of stylistic features in your code, and is a great way of enforcing a
particular style guide. How many automated checks you want to include in your development
process is up to you and the rest of your team, as is the set of checks that you want to have
flagged by these tools (all of them are configurable and customizable).
I have not even touched on the other classes of tools that can be used for software develop-
teams to share their source trees in a distributed fashion. Continuous build tools such as Hud-
son [ 57 ] automate the process of building, testing, and reporting when changes are committed.
The list of such tools goes on and on; trying to give even a brief review of them would take
up another book of this size, and would be out of date by the time the topic was in print.