Code Smell Count mismatch between SonarQube Server and SonarLint Eclipe IDE


If the JDK is the same everywhere, it should be a different issue. Would you be able to share a small reproducer (small project, or even a simple Java class) that raises issues on SQ but not in SonarLint?

Hi @Julien_HENRY
Apologies for the delay!

I’m attaching two screenshots, where Rule: “Throwable.printStackTrace(…) should not be called” is caught at one file and another file it is NOT and both the files are from the SQ server. This seems to be a new find - however, we’re trying to replicate the issue with a generic file to share.

Meantime, please let us know if you find anything with the screenshot.

thanks in advance,


Hard for us to investigate with only a partial screenshot. Could you please share a sample project on GitHub for example, with the two source files and the procedure to reproduce on a clear SonarQube instance.


Hi @Julien_HENRY

I have created a GitHub project: included with a ‘Jenkinsfile’ which has the code for sonar execution.

We had tried to run this project in our Sonar server which had variations in the report.
e.g this file: is a sample. Sonar Server has reported 4 Critical issues, however local Eclipse IDE reported only 3 Critical issue and below is the missing issue:
“Make “member” transient or serializable” is not reported in the local IDE

Attaching screenshots:
Eclipse IDE:


Please let me know for any further queries. Thanks

I don’t reproduce with the latest version of SonarLint (not in connected mode) so I guess the issue come from the version of the Java analyzer that is installed on your SonarQube server.
Can you let me know what is the version of the sonar-java-plugin your have on your server? You can call http://yoursqserver/api/plugins/installed to find the version.

  • description: “Code Analyzer for Java”,
  • version: “6.3.2 (build 22818)”

Also, have managed to push this project to SonarCloud:
with the mismatch of the ‘Critical’ issues count.


Thanks for providing all those details.

I managed to reproduce it locally and understand what was going on. We will probably have to provide a fix on our side. I just opened a ticket here.

If you encounter this problem you probably have the “Build automatically” option disabled on your project (in the Project menu). Could you try activating it, and close then open your source file to re-trigger an analysis ? This could be a temporary workaround.

We don’t plan to work on this at least before next year.
Hope this helps, keep me informed if it worked on your side.

Thanks much for the confirmation - workaround is working as expected!

1 Like

Hi @Damien_Urruty

In continuation of the issue, we were trying the same with our actual code base but we are still seeing the count mismatch. So, I have moved a sample file to GitHub:

Also, have tried to analyze this project in SonarCloud - but, the count is mismatching between the SonarCloud and Sonar Server report:
SonarCloud: - Reported 6 CodeSmells whereas our SonarServer reported only 5 CodeSmells

And, below is the screenshot of the count from SonarLint:

This is from SonarQube server:


The difference between SonarCloud and SonarQube is expected. As you mentioned at the beginning of the thread, you use SonarQube 8.2 and Java analyzer 6.3.2, which is older than what is installed on SonarCloud (where in general analyzers are up-to-date).

If I check this more in detail, Ii can see that SonarCloud raises the “Replace this alternation with a character class.” code smell. If you click on “Why is this an issue ?”, you will see that this rule is available since Dec 15, 2020, so it is a very recently introduced rule, that is probably not present on your SonarQube server.

So now if I try to summarize, for the file, SonarLint raises 9 issues, SonarCloud 10 (the +1 is explained above) and SonarQube only 6 ?

How did you add the javax.servlet dependency ? If I clone your repo, the classes in javax.servlet.* package are not found, which could explain why issues are not raised. Usually they are available in Java EE (not Java SE as you mentioned), or by adding a third-party dependency like Tomcat.

When I try locally (project bound to your SonarCloud project), I can see only 7 issues. I suspect that it is due to this dependency issue on javax.servlet APIs. You probably have the same issue when you analyze with the scanner.

I had a look at your Jenkins file, and I can see that you invoke the scanner directly. It’s easy to forget or misconfigure a property, so I recommend you use the Scanner for Maven instead, it will simplify your Jenkinsfile and maybe fix those errors. Also please make sure that you have the javax.servlet APIs available, either by using Java EE when invoking the scanner, or by adding the necessary third-party dependency to your Maven file.

Hope this helps,
Please keep us informed

Hi - Thanks for the quick reply
Apologies - I missed to commit the dependency changes done in pom.xml, it’s updated now. We are worried about the count mismatch between sonar server and sonar lint.

I have my local workspace clean inlcuding the but still having the 9 issues - meantime I will try with ‘Scanner for Maven’ - Thanks!

I updated my local copy of your project and I now have 10 issues as on SonarCloud (I am connected with it).

So in the end it’s really related to the way you configure the analysis with SonarQube. By having another look at your Jenkinsfile, you probably miss the property, which is supposed to hold all the paths to your dependency jars. This is normally handled automatically by the Scanner for Maven, that collects the dependencies declared in the pom file, so I really recommend to migrate.

Could you try to use it and keep us informed ?

Hi @Damien_Urruty

In reference with the Github project, there are no dependency JAR libraries - so have pointed to the ‘classes’ directory. Apart from these, have implemented ‘Scanner for Maven’ approach and configured the values in ‘pom.xml’.
After the above changes, have created a build and analyzed using our Sonar Server which has reported only 5 Code Smells - at the same time, with the updated project binding to SonarLint showed 9 Code Smells.
However, before sonarserver bindings (disconnected mode) showed 10 code smells in SonarLint. I was under the assumption that since the bindings/rules are downloaded from SonarServer it will be matching according to the rulesets defined in the server(haven’t modified with the default sonar settings though). Please take a look at the pom.xml/Jenkinsfile for further improvements.


Hello Ariv,

You don’t need to set and when using Scanner for Maven. They are automatically set. If you customize them, you lose default configuration.

Could you try to remove those 2 properties from pom.xml ?

Also be careful because you changed your projectKey, so this has probably duplicated the project on SonarQube.


Hi @Damien_Urruty

Have removed those 2 properties from pom.xml and I’m deleting the project from the SonarQube Server before pushing any major change to the project settings to get a fresh report.

Changes are made and committed to GitHub and analysis as well - this time ‘Issues’ count is 15 :frowning:


So now you have more issues in SonarQube than in SonarLint, right ?

For some issues like “Refactor this code to not place tainted, user-controlled data in header”, this is expected. As you can read in our FAQ:

Vulnerabilities raised by the Taint Analyzer (SQL Injection, …) are issues detected in SonarQube commercial editions that are also not detected by SonarLint (rule key starting by javasecurity , phpsecurity or ). Running tainted analysis in the IDE is currently not practical mainly for performance reason.

I think if you subtract the taint vulnerability issues, the count should match what you observe in SonarLint.

Could you confirm ?

You’re right :slight_smile:
if I exclude those ‘tainted rule’ the counts are maching between SonarLint and SQ Server. This makes us to conclude with some assumptions:

  1. Does this mean it is not valid to expect the counts to be matching for every files between SL & SQ?
  2. What will happen when the vice versa happens ie. SL produces more count than SQ - developer will spend time to fix a issue which are not going to be reported by SQ.

We were planning to make the ‘build failure’ if a developers (New) code introduces any new issues with his respective branch. In this scenario(, though this issues (tainted) not reported in SL it will still make the build failure (since it is reported only in SQ) and the developer will be nowhere to fix it to push his branch back to the main branch.

Please advice us for any further better approach. Thanks

Good news!

Does this mean it is not valid to expect the counts to be matching for every files between SL & SQ?

The only difference should be the taint vulnerabilities as mentioned and explained above, plus other cases mentioned in the FAQ linked previously.

What will happen when the vice versa happens ie. SL produces more count than SQ - developer will spend time to fix a issue which are not going to be reported by SQ.

Now that you have fixed the analysis properties and correctly use the Scanner for Maven, this should not happen anymore. You should always have more issues in SQ than in SL.

FYI we are currently working to bring taint vulnerabilities in the IDE (they will be fetched from the server). This could help with your concern that the developer might introduce a taint vulnerability without knowing it in the IDE.

As per breaking the build, there is a way to do it but we are pushing more and more to use other solutions. I don’t know what you use as an ALM (GitHub, GitLab, Azure DevOps, …) but we generally recommend to analyze at the pull request level (and your edition of SQ supports it). This way you can benefit from Pull Request decoration: your SonarQube server would automatically add a comment on the PR to show a summary of the analysis, to let developers know what is the status of the branch, if they introduced new issues and at what level the coverage is.

There is also a possibility to configure your repository to block the merge of the Pull Request while the Quality Gate is failed. There are some tutorials to configure this: GitHub, BitBucket, Azure DevOps, GitLab. This way the branch cannot be merged if it doesn’t meet your quality criteria.

If you have more questions about these last 2 paragraphs, I encourage you to open a new thread in the Get Help > SonarQube section.
I hope this helped, and thanks for your patience along the whole discussion.

Hi @Damien_Urruty
Thank you so much for the detailed explanation - I think it make more sense :slight_smile: !!


1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.