Tutorial: using FindBugs with Maven

FindBugs can be executed using Maven in two different modes: as stand-alone command or as part of the Maven site command.

These two modes require different settings in the project pom.xml but they are not incompatible to each other so we can use both of them.

info48
You can find complete Maven project here.

Stand-alone mode

Let’s start with the stand-alone mode which requires the following configuration in the pom.xml:

<build>
    <plugins>       
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>findbugs-maven-plugin</artifactId>
            <version>3.0.1</version>
        </plugin>
         ... other build plugins ....
    </plugins>
</build>

Please note that the FindBugs plugin definition is inside build – plugins section of the pom file.

Giving the following command:

mvn findbugs:findbugs

FindBugs is run against our project with the following log in the console output:

[INFO] --- findbugs-maven-plugin:3.0.1:findbugs (default-cli) @ CodeQualityGallery ---
[INFO] Fork Value is true
     [java] Warnings generated: 1
[INFO] Done FindBugs Analysis....

warning48
FindBugs analyze the compiled files (*.class). If the project is not compiled or just cleaned, FindBugs will report nothing, without error messages. So take care to build your project before running FindBugs.

A warnings number is reported on the console. Warnings are possible bugs found by the FindBugs detectors.

The warnings details are included in a report created in the file target/findbugsXml.xml which is in XML format and so not really readable.

A better way to examine the warnings is to use the FindBugs native GUI with the command:

mvn findbugs:gui

The FindBugs window shows the bugs on the left, the (read-only) code on the right and the bug explanation below.

FindBugs GUI

You can filter bugs for bug rank from the most critical (“scariest”) to trivial and even, saving project status, comparing project evolution (which means how may bugs has been eliminated/introduced after previous FindBugs check).

warning48All main IDEs (Eclipse, NetBeans, IntelliJ) FindBugs plugins show similar views and they can also let you modify the code so I don’t suggest to use FindBugs native GUI unless you have to create exclusion files (see below) which is easier with the native GUI: select a bug, filter it out and export bug filters.

 

Site mode

Maven site command is used to generate a project “site”, which is a collection of information on the project nicely reported in HTML pages. You can configure which information is included in the site report and, of course, you can add FindBugs analysis results.

Maven site requires a “reporting section” in the pom file.

<reporting>
    <plugins>       
        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>findbugs-maven-plugin</artifactId>
            <version>3.0.1</version>
        </plugin>
         ... other site plugins ....
    </plugins>
</reporting>

Giving the following command (note: clean and install options are in to assure that project is compiled and all tests run):

mvn clean install site

on the console output we will see the following:

.....
[INFO] --- maven-site-plugin:3.3:site (default-site) @ CodeQualityGallery ---
[INFO] configuring report plugin org.apache.maven.plugins:maven-jxr-plugin:2.5
[INFO] configuring report plugin org.apache.maven.plugins:maven-project-info-reports-plugin:2.8
[INFO] configuring report plugin org.codehaus.mojo:findbugs-maven-plugin:3.0.1
[INFO] Fork Value is true
     [java] Warnings generated: 2
[INFO] Done FindBugs Analysis....
[INFO] configuring report plugin org.apache.maven.plugins:maven-pmd-plugin:3.4
[WARNING] No project URL defined - decoration links will not be relativized!
[INFO] Rendering site with org.apache.maven.skins:maven-default-skin:jar:1.0 skin.
[INFO] Skipped "Source Xref" report, file "xref/index.html" already exists for the English version.
[INFO] Generating "Source Xref" report    --- maven-jxr-plugin:2.5
[INFO] Generating "Dependency Convergence" report    --- maven-project-info-reports-plugin:2.8
[INFO] Generating "Dependency Information" report    --- maven-project-info-reports-plugin:2.8
[INFO] Generating "About" report    --- maven-project-info-reports-plugin:2.8
[INFO] Generating "Plugin Management" report    --- maven-project-info-reports-plugin:2.8
[INFO] Generating "Project Plugins" report    --- maven-project-info-reports-plugin:2.8
[INFO] Generating "Project Team" report    --- maven-project-info-reports-plugin:2.8
[INFO] Generating "Project Summary" report    --- maven-project-info-reports-plugin:2.8
[INFO] Generating "FindBugs" report    --- findbugs-maven-plugin:3.0.1
[INFO] Generating "PMD" report    --- maven-pmd-plugin:3.4
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
.....

The “site” is created in the target/site dir. Opening the file target/site/index.html with the browser, we will see something like the following:

2015-06-08bIn the Project Reports section you will find the FindBugs report like the following:

2015-06-08c   The report is interesting because it give us the complete picture of our project in the summary section but also the list of the files which have FindBugs detected issues with all details including the priority (i.e. how dangerous could be the problem).

Configuration options

Regardless the used mode, the FindBugs plugin can be configured to modify and tune its behaviour. All below configurations should be placed in the configuration section of the plugin:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>findbugs-maven-plugin</artifactId>
    <version>3.0.1</version>
    <configuration>
        .....put here
    </configuration>
</plugin>

warning48
Configurations in the build and reporting sections are independent so we can have two different settings in the two modes, stand-alone and site.

Best practice is to use a light and fast configuration on the standalone mode, in order to run quick checks during development and an high effort, production quality configuration for the site mode.

Let’s examine the most important configuration options:

DEBUG: With <debug>true</debug> option, FindBugs will show what is doing during analysis. Useful to fine tune or checks the settings.

EFFORT: with  <effort>Max</effort> we can increase the time FindBugs is allowed to use to analyze the code. More effort means more accurate analysis but, of course, FindBugs run slower.

EXTERNAL PLUGINS: FindBugs can be extended with additional detectors. See my post on the topic. The  <pluginList>plugin1[, plugin2…]</pluginList> configuration option list the plugins to be used. See the sample project for a real example.

EXCLUSIONS: If you need to disable a detector or to disable the analysis on same classes, an exclude list can be specified with the <excludeFilterFile> path_to_exclude_file </excludeFilterFile> option. File syntax is documented here. An easy way to create this file is by using the FindBugs GUI which has an export filter function. See the sample project for a real example.

 

Tutorial: license headers in NetBeans (reloaded)

An alternative solution to the native NetBeans license header management (see my previous post) is the “License Changer” plugin by nhoffmann available on NetBeans plugin portal (http://plugins.netbeans.org/plugin/17960/license-changer).

The plugin is based on license template concept. NetBeans installation includes several license templates (Tools → Templates) for the most popular Open Source licenses: 2014-02-25_pic01The plugin uses one of the available templates. If you have your own license file, you have to include it in the template list (but the plugin help on this).

NOTE: all custom license files will be saved in the NetBeans User Directory. You can have a look at the beginning of View → IDE Log for your real path.

With the plugin we can do more that native NetBeans solution except for one use-case: when you have a proprietary and project specific license. In this case NetBeans let us save the license file within the project (so all team members can use it) while, with the plugin, all licenses are stored in the user NetBeans installation (which is not shared across the team).

Let’s describe now the plugin.

After plugin installation, you can select a file or a package and apply “Change License Header” (see picture below).

2014-02-25_pic02A wizard starts. On the first page we can select the files types on which the plugin should operate on (see 1). Nice added feature is the possibility to change the line endings character (see 2).

2014-02-25_pic03

 

Second page of the wizard is the following:

2014-02-25_pic04

We can select the license from the template list (see 1) or browse the disk for a custom license file (see 2) which will be included in the template list by the plugin.

IMPORTANT: The checkbox “Set as default project license” (see 3) is very important. If checked, the plugin will save the selected license in the project configuration (the same used by native NetBeans solution). All new created files (including file types not supported by the plugin) will inherit the setting and they will have the correct license header.

After license selection:

2014-02-25_pic05The rest of the wizard is very simple.

NOTE: One little annoying problem with the plugin is that the selected license is not kept for the following plugin invocations.

Typical procedure :

  1. install the plugin
  2. run the plugin on a project file or package or folder,in order to include all existing project files
  3. use standard NetBeans File → New File procedure to create new project files

Improving NetBeans FindBugs integration

In NetBeans 7.4, the FindBugs integration inside the IDE has been improved giving us the possibility to specify additional rules to be checked.

FindBugs has a plugin architecture that let user to add custom rules sets. I usually add FindBugs rules from FBContrib, a FindBugs auxiliary rules set.

There are hundred of rules included in FBContrib. Complete list can be found here.

What is amazing in NetBeans is that not only you can tell the IDE to use the additional rules sets but that the new rules are seamless integrated in the NetBeans interface. For example, FBContrib rules are grouped together with standard FindBugs checks.

First step is to specify the path to the FBContrib jar file (downloaded from the FBContrib website) in the FindBugs configuration (Options –> Editor –> Hints –> FindBugs )

2013-10-22b-fig1

Press “Custom FindBugs Plugins” button.

2013-10-22b-fig2

The “Add” button let us specify one or more additional jar files.

As I already mentioned, the rules included in the FBContrib jar file are integrated with the other native FindBugs rules.

See for example, the rules related to the “Secure” description before

2013-10-22b-fig3

and after FBContrib has been specified:

2013-10-22b-fig4

Both native and FBContrib rules can be enabled and disabled one by one.

With NetBeans Hints, FindBugs and, may be, PMD (see this post on PMD plugin ) all enabled there is a good chance that one problematic line can have more than one warning. In this case I suggest to keep native NetBeans hints enabled and disable the check in the other tools, mainly because NetBeans native checks are faster.

PMD in NetBeans: the EasyPMD plugin

PMD is a powerful source code quality checker which analyze our code and report bad coding habits, failures to respect naming conventions, inefficiencies and many others.

PMD has an internal list of rules to be checked. Rules are divided in sets. Each set contains several rules.

For example the “Comments” set includes all rules related to code comments.

PMD rules sets are documented here.

On my opinion a PMD rule violation should be intended as a suggestion to better check the code to be sure that the offending code line is really what we want to have. Often PMD is right to say the line should be fixed or at least improved.

In NetBeans PMD is enabled by the EasyPMD3 plugin available from NetBeans plugin area and from the plugin home page ( http://gianlucacosta.info/software/easypmd/ ).

Note: There is an enhancement request to introduce native PMD support in NetBeans, like what has been done with FindBugs.

One very important point to remember is that EasyPMD (and so PMD) is controlled by the “Action Items” window settings. Just click on the “Action Items” window filter icon and check that EasyPmd notifications are enabled. If not enabled,PMD will not check the code.

2013-10-05a

When enabled, PMD checks Java code and

  • reports in the “Action Items” window all rules violations
  • marks as a blue circle the lines in the open editor window that contain a rule violation

2013-10-05b

In the above picture, PMD reports that the field callCount is initialized to zero but this is a meaningless operation because zero is the default value for numeric fields. Actually this initialization will cost us few cpu cycles.

This is the PMD “RedundandFieldInitializer” rule belonging to “Optimization” rule set but there are many others.

Some PMD rules conflict with NetBeans hints because they check the same situation.

2013-10-05c

The processFindForm() method in the picture reassigns one of its parameter (owner); PMD reports it at line 86 while NetBeans at line 106.

I usually disable the PMD rule if there is an equivalent NetBeans hint, also because some NetBeans hints give us the possibility to fix the problem with a dedicated refactoring (but not the one in the picture). PMD is an pure analyzer so it does not perform any change in the code.

There are several rules and rules sets available in PMD but not all of them are relevant for us. For example the “Android” rule set is of course not interesting for Java EE applications.

Thankfully we can select rules set and single rules we want PMD to check.

EasyPMD give us two approaches: select the rules sets to use but not the single rules or full freedom in rules and rule sets selection.

The first approach can be done with the EasyPMD UI interface (Tools –> Options –> Miscellaneus –> EasyPmd3):

2013-10-05d

The list in the picture contains all rules set we want PMD to check. Single rules can be included or removed with the “Add Standard” and “Remove” buttons.

The alternative solution (full freedom) requires a preliminary activity: to prepare a jar file with the PMD rules set and rules we want to be checked. Detailed instructions to prepare the rules jar can be found here.

The basic idea is to create a xml file with contents like the following:

<?xml version="1.0"?>
<ruleset name="Custom ruleset" xmlns="http://pmd.sourceforge.net/ruleset/2.0.0">
<rule ref="rulesets/java/basic.xml"/>
<rule ref="rulesets/java/comments.xml">
    <exclude name="CommentSize"/>
</rule>

In the fragment above, I selected the complete “basic” rule set and the “comments” rule set except the “CommentSize” rule.

Source and jar file I use can be found here

Once the jar file with rules has been created, we instructs EasyPMD plugin to use it:

2013-10-05e

The rules jar is also useful to share PMD rules across the development team. The jar file can be placed in a shared area and all team members can refer to it in their (local) EasyPMD configuration.

Checking JavaScript in NetBeans

NetBeans 7.3 has introduced an improved JavaScript support, including a wider support for JavaScript code checks. It is also possible to install a JSLint plugin for stronger code checking.

Let’s start with NetBeans native capabilities. In the Tools -> Options -> Editor -> Hints we can find all NetBeans code quality checks, divided by language.

The following picture shows the JavaScript checks:

2013-05-22_fig1

In the following picture we see how the NetBeans JavaScript hints work:

2013-05-22_fig2

This is nice feature to have so we can fix the errors while we are coding. Unfortunately the NetBeans JavaScript checks are limited (in number) and we should use an external plugin to enforce our code checking rules to our js files.

JSLint is the reference JavaScript quality checker. A good JSLint plugin for NetBeans is available here.

To install it in NetBeans, juts follow this simple procedure:

1. Download the plugin on the PC

2. Open the Plugin window in NetBeans (Tools -> Plugins) and click on the “Downloaded” tab.

3. Click on “Add Plugins” and select the downloaded file.

2013-05-22_fig3

4. Press “Install” to start JSLint plugin installation.

After installation, we can go back to our file and check it now with JSLint. Open the context menu (right mouse click) and select “JSLint”. In the Action Items window, we find all errors detected by JSLint on our file.

2013-05-22_fig4

As we can see in the picture, JSLint is more restrictive than NetBeans, showing more errors (3 in our small example). For the complete and reference list of JSLint checks please refer to the JSLint author page.

If the Action Items list contains errors on other files in the project and in particular on libraries files (like jQuery and Bootstrap js files) we can easily filter out them. We can create an Action Item Filter as shown in the following images:

2013-05-22_fig5

2013-05-22_fig6

JSLint plugin configuration can be found in Tools -> Options -> Miscellaneous -> JSLint (tab). The options set on this page are valid for all JavaScript files in the project. In the next picture, the configuration I usually use in my projects:

2013-05-22_fig7

Basically I limit line length to 80 characters and define window as global variable.

File specific settings can be defined as follows:

/*jslint sloppy:true */
/*global window */
function myFunc(txt) {
window.alert(txt)
}

The /*jslint contains JSLint configuration parameters while /*global defines implicit global variables (defined outside the current file). Important: there should be no space between the asterisk and the words jslint and global so take care that NetBeans formatting will not try to format Javascript comments.