squid:UselessImportCheck issues not being picked up consistently

  • SonarQube 8.2
  • squid:UselessImportCheck issues not being picked up consistently
    Language used: Java

Hello @scao,

It would be great to provide some details, a reproducer at minimum because right now there is nothing we can do to help with the level of information you provided.


Hi @Alexandre_Gigleux,

In our projects we are seeing sudden build failures with quality gate issues introduced from previous merges. But we have set things up so that those failures should have occurred and prevented the merges from succeeding in the first place.

I’ve been testing by adding unused imports into a file, 2 of the same just to be safe, and then running sonarqube check from the command line. Even though the rule is activated as a code smell, I’m showing as having passed quality gate with 0 code smells.

The other fault that I introduced which also has not been picked up is S00113 (no new line at end of file).

I have tried upgrading the unused imports rule to Major from Minor issue, and the same thing happens.

I have also confirmed that the code section on sonarqube UI is showing my changes each time.

As far as I can tell, the behaviour is inconsistent, because uselessImportCheck code smell definitely fails the quality gate some times.




I believe the misunderstanding is coming from the fact that the default Quality Gate is using the metric Maintainability Rating. This measure is not looking at the number of Code Smells but it looks at the density of Code Smells compared to the number of LOCs. Having a A rating for Maintainability Rating doesn’t mean you have 0 Code Smells. Check the exact formula here: https://docs.sonarqube.org/latest/user-guide/metric-definitions/.

I believe in your case it happens that a couple of issues raised by squid:UselessImportCheck make the Maintainability Rating measure reaching the threshold that triggers the failed Quality Gate.


Hi @Alexandre_Gigleux,

Thanks for your response.

Just to clarify, if I have introduced 2 redundant imports and 1 file without new blank line, is the expected behaviour:

  1. What happens now in our project: Passed quality gate due to A maintainability rating, and the UI showing 0 Code Smells as in the attached picture;
  2. What is currently not happening in our project: Passed quality gate due to A maintainability rating, and the UI showing 1-2 Code smells.


The expected behavior is the second one: you should normally see 2 New Code Smells.

Are you sure the new lines are well detected by SonarQube when you go on the Code page?

Do you reproduce the problem when you analyze a Branch or a Pull Request?


Thanks @Alexandre_Gigleux

The problems can be seen on both Branch and Pull Request analyses.

On the code page: the unused imports are both highlighted as in attached picture, so is line change for new line.


S1128 (aka: UselessImportCheck) doesn’t raise an issue on imports ending with a *.
So in your case, it’s expected to not have an issue for java.awt.font.*

Note: it will raise an issue for java.lang.* because java.lang classes are always implicitly imported.

For the line ending problem not reported, would you be able to share a reproducer so we can try to debug the problem here. There is certainly something weird at the end of the file that we detect as a line end character while it’s not the case.
Also knowing what is the file encoding used by the file and the encoding used by the code scan would help (parameter: sonar.sourceEncoding).


Thanks @Alexandre_Gigleux!

encoding is UTF-8.

How do I get the reproducer?


It’s not possible to automatically generate a reproducer for Java (while it’s automatically done for C/C++/Objective-C): you will have to find a way to reduce your case to something very simple (requiring the minimum of dependencies) and not containing code related to your company.


Thanks @Alexandre_Gigleux can you explain a bit more what I should share as part of this ‘reproducer’?

A reproducer is an archive made of some Java files, a build script (pom.xml, gradle file, …) that can be scanned out of box. You can even think about sharing your reproducer as a public GitHub repository.