Monthly Archives: August 2014

Create a PMD and a FindBugs Configuration as a Reusable Configuration Resource jar File

As with the Checkstyle configuration, it is often useful in centralized build environments to bundle the PMD rules into a dedicated jar file. The benefits of centralizing the FindBugs excludes file are, in my opinion, somewhat limited. While establishing a centralized set of Checkstyle and PMD rules often makes a lot of sense, the files to exclude from a FindBugs scan often depend on the sources of a particular project at hand, and are seldom generic enough to justify centralization.

The mechanism for creating a configuration resource artifact for PMD and FindBugs is very similar to the process used for Checkstyle: Create a new Maven project and store the PMD configuration file (e.g. pmd-rules.xml) and the FindBugs excludes file (e.g. findbugs-excludes.xml) in the src/main/resources folder. As with Checkstyle, there is no need to configure the PMD of FindBugs plugin for this Maven project. Once you have created the artifact, perform an “mvn deploy” and push the (versioned) artifact to a repository server.

Edit: See the “build-tools” project in for an example on how to create PMD and FindBugs Maven configuration artifacts.

Improve Code Quality and Security by using Findbugs in Maven Builds

Other than Checkstyle and PMD, FindBugs is a general purpose code quality static code analysis tools that comes with dedicated checkers for security related defects. However, in over 400 FindBugs checkers, there are less than a dozen dedicated security checkers. This makes the security specific portion of FindBugs comparatively small.

Like Checkstyle and PMD, FindBugs can help developers writing better code by making them reflect about whether the code they are creating really does what they think it does. FindBugs can discover many rather subtle bug patterns that stem from incorrect language use, e.g. when doing comparisons, bit shift operations, and type conversions. In addition to that, it also covers many bug patterns around code correctness, multi-threading, and general best coding practices that a developer should generally follow. The FindBugs documentation provides an extensive list of what the latest release is covering.

FindBugs follows an interesting configuration pattern in so far as a developer cannot necessarily choose which checks to execute, but rather controls the precision of the analysis and then creates a filter file during result auditing:

  • Instead of specifying a list of checks to run, FindBugs takes an “effort” parameter that specifies how “precise” the analysis should be, and a “threshold” value that determines a severity threshold that a bug must exceed to be reported. More effort means more CPU time and memory being spent on the analysis. Lower threshold results in more of the bugs that have been found being actually reported.
  • FindBugs allows to ignore (“filter”) certain bug categories in the reported result list down to a single class/method level, as well as exclude specific files and file patterns from the analysis. The manual gives a great example on the fine granularity of the filter mechanism.

The filter configuration basically represents the result audit, as it is required to add a new filter entry for every false positive that should be removed from the report. This is somewhat clumsy, because it separates the audit tracking from the code, and FindBugs cannot easily recover in case code that has been previously audited is being refactored. Other tools work with annotations (e.g. PMD) or comments (e.g. Checkstyle) that are embedded directly into the code, which bundles the audit results with the code and therefore allows both atomically revision controlled and more refactoring safe source code auditing.