Findbugs is really good solution to improve quality of code
As an author of findbugs-slf4j, I really love Findbugs. It lets us find problems by static bytecode analysis. This tool improves quality of each module, reduce reproducing known bug, and point problem quickly in IDE. We do not have to use code review to find known problems and/or antipatterns, Findbugs will do it before developer sends pull-request. This 'push notification' is really cool, we can point problem even if developer has no motivation to find it.
It is really ideal solution also for large scale development team. Even if your team has hundreds developers, they can get help from Findbugs from the beginning of working day. Even though some of them have less experience and knowledge about our depending framework, module and language, Findbugs can help them to catch up quickly.
Findbugs is constructed based on both academic and practical experience, and now it's OSS so not only limited contributors but also everyone who wants to improve documentation comment, message translation, new detectors and so on.
Problems in Findbugs
But I have a dream to implement Findbugs alternative, to replace Findbugs with better implementation. In my personal opinion, it has some problems:
- Difficult to maintain: Less documentation comment to describe usage*1, Less fresh document to describe (e.g. how to implement plugin), Too wide scope,
- Slow performance: Not ready to use multi-thread so efficiently. No support for incremental analysis provided by build tools.
- Difficult to test: To test Findbugs plugin, test-driven-detectors4findbugs was good solution but it doesn't work with Findbugs 3.0.1 due to internal implementation change. We also need a hack to test by Maven.
Yes Findbugs is OSS, so in theory we can solve them by own. But recently this project is not so active, and there is no popular fork for now. It would be problem to solve.
New alternative: error-prone
Last week I found an interesting static analysis tool, named error-prone.
This does not check bytecode, it applies hack to javac so it handles AST under com.sun.source.tree package.
In my understanding, it has many good points:
- Providing automated correction.
- Providing simple but enough guideline, so we can write unit test to test rules to detect bug pattern.
- It's product from Google so it has detailed documentation comment.
- Using Annotation Processor to manage metadata of bug pattern, so we do not have to maintain XML files,
I haven't tried it with large amount of code, so I cannot compare its performance with Findbugs yet. I hope it's better than Findbugs. About openness and activeness in its community, I'm not sure yet. I've sent a pull-request to add bug pattern, I hope it's open even to non Google developers.
Do we need to switch to error-prone?
In my understanding, problem in error-prone is as follows:
- support JDK8+ only: Your compiler should be JDK8+
- no multi language support: Message is hard-coded in .java file
- no plugin mechanism: To add bug pattern, we need to update error-prone itself
- less bug pattern: Findbugs 3.0.1 has really many bug patterns but error-prone provides just a little
So if you're using Findbugs, I think you do not have to switch to error-prone for now, its merit is really limited and almost all of them are not for users but for contributors.
But if you're author of Findbugs plugin, I think error-prone has value to keep watching on it. If its agility and resource is enough, it might grow and replace other solution later.
*1:I've sent some patches and pulll-requests but it's not enough yet
