Java analyzer v6.0: more accurate analysis, with fewer false-positives

Hello Java developers,

During the last 6 months we did a full rewrite of our Java analyzer and its 550+ rules to use the Eclipse Compiler for Java (ECJ, part of Eclipse JDT Core Component). Why? ECJ offers an incredibly more precise semantic resolution, which leads to more accurate results and fewer false positives for rules that use semantic information. In addition to the overall improvements, this move allowed us to fix 24 bugs and 19 false-positive tickets.

Support of Java 13

You can now analyze your Java 13 code. Only preview features of Java 13 are supported (new switch expression using “yield”, text blocks). Preview feature of Java 12 (switch expression using “break”) is no longer supported and files using it will be ignored.

Java API for Custom Rules

The rewrite of the Java analyzer changes nothing in the existing public APIs. Custom rules should continue to work as before. Custom rules using the symbol table will also benefit from the new increased accuracy and raise fewer false positives.

Rule Identifiers

To be consistent with the other SonarSource analyzers, the rules’s identifier was changed from “squid” to “java”. This should be mostly transparent on all SonarQube instances (>= 7.9 LTS) and SonarCloud with the exception of the use of @SuppressWarnings referencing squid identifiers, which was forgotten and will be fixed by (fixed by v6.0.1)


Unfortunately, the accuracy gain comes with a performance cost. You may experience some performance impacts on your analysis (in some cases it can be two times slower). We will try in the coming months to reduce these impacts.

Edit 2020-01-28: if you are facing huge performance regression, please create a dedicated thread so we can easily exchange with you.

JaCoCo Binary Format

The JaCoCo .exec format is no longer supported. This feature was deprecated in April 2019. Java projects should now use on the JaCoCo XML format for coverage, as described here: [Coverage & Test Data] Importing JaCoCo coverage report in XML format

Rules Changes

The rule S3340 (Annotation arguments should appear in the order in which they were declared) is removed because annotation argument order can not be guaranteed when reading from bytecode.

The rule S1188 was split into two distinct rules:

  • S5612: Lambdas should not have too many lines
  • S1188: Anonymous classes should not have too many lines

For more information, see the changelog.

The new Java analyzer is already available on SonarCloud. For SonarQube users, these new features will be built into the next version (8.2). In the meantime, you can get them now by upgrading to v6.0 of the Java analysis engine.



A post was split to a new topic: SonarJava 6.0.1 is slower than 5.14 and this impacts our PR analysis time

A post was split to a new topic: SonarJava 6.0.1 3 times slower than 5.14

The performance impact of v6.0 is more significant than expected with some users reporting analyses that are 4x slower than before.
While we still believe the changes in 6.0 are overall beneficial we also take the performance issues seriously, and hope to have good news in the coming weeks.

1 Like


I’m happy to announce that the v6.3 of the Java Analyzer is fixing most of the performance degradation introduced with the v6.0. According to the tests we run, analysis are almost back to the performance of the v5.14. If you don’t see any improvements while upgrading to v6.3, we would like to exchange with you. So don’t hesitate to report it on a dedicated thread.

Here are some figures from our tests:

You can see from these graphs that the move to ECJ was not the root cause of the problem. We had to rethink how rules were written to make them performing efficiently.

The Java Analyzer v6.3 is available for download now for SonarQube users and will be deployed in the coming hours/days on SonarCloud.

Big kudos to @Godin for the huge work! :metal:



I made the update to SonarJava 6.3 on Sonarqube 8.2 today and afterwards all issues that were suppressed by @SuppressWarnings appeared again and I had to close them as false positive in SonarQube.
Anyone else seeing the same problem?

But performance is much better, only needs half of the time as before.

1 Like

It’s also a problem for me, @SuppressWarnings looks not working anymore, right?
E.g. @SuppressWarnings(“javasecurity:S5131”) which worked before, stopped working