TL;DR overview
- SonarQube has deprecated 158 CheckStyle and PMD rules that are now fully covered by SonarQube's own Java rules, reducing duplication and simplifying Java analysis configuration.
- This consolidation ensures developers working in Java receive consistent, actionable feedback without redundant or conflicting rule sets cluttering their issue lists.
- Teams currently relying on CheckStyle or PMD for Java analysis can migrate to SonarQube's built-in rules for equivalent—or more comprehensive—coverage.
- The change reflects Sonar's ongoing effort to provide a single, authoritative source of code quality rules, reducing noise and enabling developers to focus on the most impactful issues.
Recently, we released the SonarQube Server Java 1.4 plugin ecosystem, and as announced in What's coming up for SonarQube Server in 2013, we're working hard to progressively deprecate as many Checkstyle and PMD rules as possible, and write native replacements for them using the SonarQube Server Java rule engine. We'll continue to support both tools for the foreseeable future, but the goal is to remove them from the default SonarQube Server Java plugin ecosystem package.
Fans of those two mature, well-known Java quality tools may wonder why we're moving away from such popular tools. There are in fact several good reasons behind this move :
- Productivity: the activity is low on both projects. In the past, we invested time in updating both tools to support the new language features in Java 7, but in the long term it's not a viable approach for SonarSource. Continuing to support these tools - both directly with our commits to those code bases, and indirectly - means to working on three different source code analysis stacks: Antlr for Checkstyle, Javacc for PMD, and SSLR for SonarQube Server's own Java rule engine.
- Performance: analyzing a project with SonarQube Server while using Checkstyle and PMD rules leads to parsing the same Java files three times: once each with Antlr, JavaCC and SSLR
- Functional overlap between rules: There is a big overlap between Checkstyle and PMD rules (and in fact even with some Findbugs rules), which makes it difficult to define and manage a Java quality profile.
- Too many configuration options: in a perfect world, a good quality rule is a rule WITHOUT any configuration options. The user should not have to understand what a token is, or what an AST is, and he should not have to tune configuration options to start playing with a rule. On new SSLR rules, we do our best to cover all the use cases, to avoid generating false positives so the user isn't bothered with configurations.
- Rule descriptions: however perfect a rule implementation is, the rule is worthless without a good description. A rule's description should always clearly state its purpose, so the reader isn't left to experimentation to truly understand what a rule does.
None of this is to say that Checkstyle and PMD aren't great Java tools with wide user bases. They are. But whatever we do at SonarSource, we always try to do it with the long term in mind. And in the long term, it's well worth migrating existing Java rules to the SonarQube Server-native Java SSLR engine.