Static analysis tools for Java landscape in 2016

In two recent articles I was talking about mistakes in using static analysis and kinds of static analysis tools. As a last part of this mini series about static analysis I would provide my preferred toolset for Java landscape. As I am mainly Java developer and I am in industry for more than 8 years, I have experience with various tools. There are pretty good possibilities for choice and many of them are providing possibility to extension. Maybe I am wrong, but there is no significant new big player or game changer in static analysis so the year 2016 in title can be easily replaced with 2015 or even 2014.

How to incorporate tools to the project

Frankly, I would pick one tool for each category provided in last article and incorporate them into project. This is probably very exhausting goal on the start so I would start with one tool and incrementally add the next ones. I would prefer to start with incorporation of tool checking potential bugs - without any doubt any violation or warning means possible bug or mistake. After solving violations, incorporation to build lifecycle and being familiar with the tool I would add next tool - about bad practices checking. And the last one would be checking code conventions as these are most discussed and hard to agree among team members. So start with subset of rules and continuously add further.

Recommended tools for Java development for each category

Conventions
- Industry standard:http://checkstyle.sourceforge.net/[CheckStyle]
  - Allowing creation of own rules. Check this.
  - Additional checkstyle rules
- IDEs code inspections
  - Even when these rules aren’t enforced by build process, it’s critical to use shared settings of these inspections through team members. It can be set to be playing the same game as a static analysis tools and avoid unnecessary failing builds.
Bad practices
- Industry standard: PMD
  - allowing creation of own rules. Check this.
- Other possibilities
  - JDepend - cyclic dependency tool, it’s complementary to PMD and may come with more violations than PMD.
Potential bugs
- Industry standard: FindBugs
  - Can be used as analyser for libraries when source code is not available as well (to get impression about quality of such library).
  - Additional detectors for FindBugs.
- Other possibilities
  - Error Prone - is checking bugs at compile time so it’s fail-fast static analysis tool.
  - Infer - Facebook last year tool for finding bugs seems to be pretty ambitious but as the authors are saying - it’s a long way to have comprehensive set of rules inside and they are still on the start. It seems that theories stands behind this software are very reasonable so it can be future of static analysis in further years. Nice thing is that it’s running only on the changed code so it’s significantly faster than other tools which are starting from scratch all the time.
Architectural issues
- Macker
  - Last update 2013, no clear future.
  - Macker is checking architecture problems, for example using database access code directly from UI. It is configurable and provides further benefits upon CheckStyle rules. So it’s supporting good conventions on the code.
Code coverage
- JaCoCo
- Cobertura
- Clover (commercial)
- Comparison of tools - comparison of code coverate tools by Atlassian and another usefull comparison.
  - Well, in this category is my opinion not strong. Each of these tools works pretty well and have similar outputs. If it’s not problem with money I would reccomend Clover which has more metrics than others, it’s able to show top risks and it’s actively developed and supported.
Have it all toghether
- Qulice
  - This is most complete tool for static analysis which I have seen so far. It combines PMD, FindBugs, CheckStyle, Cobertura and plenty of own rules. It breaks build for even the smallest violations so it has great positive impact to the codebase.
- SonarQube
  - Sonar is great for aggregation of PMD, Checkstyle and Findbugs reports to providing big picture about software. Sad thing is that it’s only read-only thing and rarely is someone starting action after checking sonar report. This is why I would recommend using Qulice.

Conclusion

The last statement - please, use static analysis in even smallest project. As I stated in last article, there is significant chance that you and your team will learn something and become better developers. Start with small set of rules and incrementally enhance static analysis with additional rules and even tools.

P.S. If you enjoyed this post, you can follow me on twitter to stay in touch with my further articles and other thoughts.

P.S.2 Cover image by Todd Quackenbush | unsplash.com.