A SpotBugs Migration Journey
A guide on how to migrate your Maven applications from FindBugs to SpotBugs
At Hotels.com™ (part of Expedia Group™), we are migrating some of our Maven projects to use SpotBugs instead of FindBugs, and we have contributed back to its open source to ease the process for others.
We use a variety of plugins that report potential issues within our code such as possible bugs or inconsistent code style. FindBugs performs static code analysis to find potential bugs that are classified into four categories: ‘scariest’, ‘scary’, ‘troubling’ and ‘of concern’. The plugin produces a report with details about all the bugs it finds that can be displayed in tools like Jenkins.
Unfortunately, as of 2016, FindBugs is no longer actively developed. But fear not! The self-proclaimed spiritual successor of FindBugs — SpotBugs — continues the work of Bill Pugh and David Hovemeyer, the FindBugs creators.
FindBugs has always been very beneficial to us because of the insights it provides into issues (or serious vulnerabilities) that might have been missed by developers. For this reason, we started to investigate whether we could use the fresh new SpotBugs as a drop-in replacement for FindBugs.
Drop in SpotBugs
The first step was to find a test project that used FindBugs and strip it of its FindBugs dependency:
and slot in SpotBugs instead:
The good news is that SpotBugs works in exactly the same way as FindBugs — you can use the same configuration settings and the exact same exclude-bug filter file:
Running the SpotBugs goal will also produce an output file in the same format as FindBugs, but with a different filename
spotbugsXml.xml (where the FindBugs report was called
The testing was looking promising until we hit one little snag: SpotBugs requires you to be using Java 8 (intense developer discussion on the issue found here). This means we need to use FindBugs for our Java 7 projects, and then use SpotBugs with other projects moving forward.
Integration with Jenkins
A great benefit of FindBugs is the integration with Jenkins, which most of our projects use for CI/CD. For example, in Jenkins 1.x, you can use the FindBugs Warnings Plugin to display the results of your FindBugs analysis. It’ll guide you through the code, showing you where it picked up the bugs.
The graph gives a quick, snappy summary of bugs found and links you to a page where you can see more details about the bugs:
Displaying the report results like this is convenient because we don’t need to do further processing of the output XML file to figure out what we need to fix.
So now the next step was to find out if SpotBugs could be used with the Jenkins FindBugs Warnings Plugin as is. Jenkins 2.x has a fabulous plugin called Warnings Next Generation Plugin which allows you to display both FindBugs and SpotBugs reports, so if you are using Jenkins 2.x, you don’t have to do anything else.
The big “but…”
But we soon realised that many of our projects are being built on Jenkins v1.6 and no plugin exists to display SpotBugs reports on it. It turns out the Warnings Plugin is hardcoded to exclusively scan for XML files with
findbugs in the filename within the build workspace to generate the graph and the name of this file is not configurable in the plugin.
We could quite easily create a bug report using SpotBugs that was basically the same as FindBugs, but we couldn’t display it in Jenkins with the Warnings Plugin because it didn’t have the
findbugs keyword in the filename.
We tested the diffs between reports and concluded that they were similar enough for us to try and find a way to rename the output file.
After a short Googling session, it was discovered that other people had come up against the same problem. Another developer had opened an issue on the
spotbugs-maven-plugin GitHub repo describing similar woes of hardcoded FindBugs filenames and suggested making the output filename configurable.
This seemed like a wonderful solution to our own problem, so our task was cut out for us. Implementing the feature ended up being a relatively painless process all-in-all. The maintainers of the plugin were helpful and approachable regarding issues and pull requests on the project.
Once we’d written the code and sufficiently tested it internally, we submitted a pull request to the
spotbugs-maven-plugin GitHub repo and sat back to wait in suspense. Within a few days our contribution was reviewed, merged into the project, and we were promised a release within a couple of weeks. The change has now been released as version 126.96.36.199:
If you want to rename your SpotBugs output file, simply add the following in your Maven pom file’s configuration section:
All you need to do now to get the Warnings Plugin working is run the
spotbugs:spotbugs goal during your build. The Warnings Plugin should then create a nice graph representation of your bug report made with SpotBugs, without needing to change anything else.
The migration from FindBugs to SpotBugs is relatively simple as long as you can jump over the Java 8 hurdle. Generally, you can just replace your old FindBugs dependency with SpotBugs, but if you have a project that explicitly requires FindBugs output files, just use the useful rename feature from the release of SpotBugs version 188.8.131.52 as described above.
This was my first attempt at contributing to an open source project and it was a great experience that taught me plenty about good coding practices and working with people outside of my own team. If you haven’t worked with open source projects before, I highly encourage you to implement a useful feature that others are looking for. Generally, the community is very supportive and constructive in feedback, so making a contribution will always be a good learning opportunity.