The issues don't appear on Eclipse IDE with SonarLint but are present on SonarQube


We have some problems with SonarLint. SonarLint is bind of our Sonar server.
Some issues don’t appear with SonarLint in Eclipse IDE.

For example, the rule “java:S1172: Unused method parameters should be removed”.

In SonarQube:

In Eclipse with SonarLint only one issue but is not that. :

Do you know why ?
Thanks for your help.


Hello, thanks for reporting this!

This could be due to a difference in the version of the Java analyzer between SonarQube and SonarLint.

Could you please make sure that:

  • your local project is bound to the correct server project
  • your project binding is up-to-date (from the “SonarLint Bindings” view, right-click on your server, “Update All Project Bindings”)
  • your local project correctly builds in Eclipse: the Java analyzer reads some data from the byte code, and if the project does not build correctly, the byte code might be out of sync and the analysis precision can suffer


Thanks for your reply.

All of theses points are correctly realised.

A mvn CMD are executed to analyse my project in Jenkins job : Maven use Java 1.8.

  • mvn sonar:sonar -Dsonar.projectKey=dossier-electronique -Dsonar.login=**** -Dsonar.login=****\Applis\Jenkins\workspace\dossier-electronique-pipeline/dossier-electronique-commun/target/classes/**,E:\Applis\Jenkins\workspace\dossier-electronique-pipeline/dossier-electronique-service/target/classes/**,E:\Applis\Jenkins\workspace\dossier-electronique-pipeline/dossier-electronique-war/target/classes/**

Eclipse build my project with Java 1.8 too:

Hey, thanks for the additional info.

I am a bit surprised that the Maven command line you use for the SonarQube analysis manually specifies the property: in Maven, the scanner should feed it automatically with each module’s build output directory (as well as using each module’s dependencies).

I also notice in your editor screenshot that method getJSONFromListeDocument is marked as implementing a declaration from an upper interface or abstract class (with the little white arrow in the margin).

IIRC, rule java:S1172 has an exception for such a case: it should not raise an issue for unused parameters on overrides and implementation methods.

So I believe that what is happening is that:

  • In SonarLint, the Java analyzer correctly resolves the implemented interface/abstract class (using the class path configuration provided by Eclipse and/or M2E) and does not flag the “unused” parameters;
  • In SonarQube, the Java analyzer gets confused (probably by the manually set property), does not resolve the implemented interface and thus wrongfully flags these parameters as unused.

In a perfect world, I would advise you to remove the manually set from your analysis command, unless you have a very good reason to keep it; but I am not quite sure what would be the impact on your project’s analysis history.

If this is not an option, I would advise that you mark this particular issue as a false positive on SonarQube.

Thanks Jean-Baptiste, I understand the problem now, this is because of the exceptions of the rule…

But we need to use the property If we don’t specify that, some issues appears like “java:S1948:Fields in a "Serializable" class should either be transient or serializable” because the project is multimodules and the current module has no visibility on any other module.

For example :
In Service Module :

public class MyClassInServiceModule implements Serializable {

In War module:

public class MyClassInWarModule implements Serializable {
    private MyClassInServiceModule service;

If I don’t specify this property “”, i have an issue in this case on object MyClassInServiceModule service.

Edit: Excuse me, it was an error. The issue appeared because I used an interface and no the class MyClassInServiceModule directly. It’s a false positive.
So, I deleted the property and the issue of rule java:S1172 disappeared.
Thank you for your help.

1 Like

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