Details
-
Improvement
-
Status: Done
-
Major
-
Resolution: Done
-
0.3.0
-
None
Description
From on a discussion thread I kicked off on the dev list. Some newer notes follow
Original Email
I wanted to kick off a discussion about integrating a static analysis tool into our builds.
The main discussion points I wanted to start up (and feel encouraged to add more):
1) Most importantly, do we get enough value by adding a tool?
2) What are we looking for out of a tool (Extensibility to add our own checks, plugged into build cycle directly, ease of use, customizability, etc.)?
3) Are there any particular tools people have experience with?
4) Assuming we want to roll something out, what's the best path? My current assumption is that it's probably easiest to handle things on a pom by pom basis, rather than trying to do everything at once, but there may be more nuance people want to add.
The main one I've used FindBugs, but there's a been discussion lately about issues with their community which led me to take a (very) brief glance at into Google's errorprone. It seems like it's an alternative worth considering from what I've seen.
Some links to errorprone info:
http://errorprone.info/
https://github.com/google/error-prone
http://errorprone.info/bugpatterns
I played around with it for about 2 minutes, and was able to get it up and running and happily complaining about metron-common during it's build cycle. Haven't dug too much into the errors/warnings to get a sense of signal to noise ratio. If anybody is interested in playing around with that setup for metron-common, I have a branch at:
https://github.com/justinleet/incubator-metron/tree/errorprone
Just go to metron-platform/metron-common and run:
mvn compile
Gist with the error prone output.
https://gist.github.com/justinleet/8d514727a0caeb5db2b4f76de0607214
New notes
After playing around with error prone a bit more (I was able to get it running on most of our modules and fix build breaking errors pretty quickly), it provides significantly less check coverage than findbugs, but has the benefit of being directly tied into the compile (meaning people can get feedback and errors pretty quickly). Related to this, the errors that error prone gave out were actual issues (although relatively minor in our codebase, e.g. catching issues with format() calls).
It seems the benefits of error prone fall primarily on it coming earlier in the lifecycle to give feedback quicker and being actively maintained and improved.
The main benefit of findbugs is being a broader set of checks, but at the expense of being later in the build cycle (because it operates on bytecode), and the community being in an odd place right now.
Attachments
Issue Links
- links to
