I tried to suppress some sonar rules with Java’s @SuppressWarnings.
To use meaningful names I prefer using constants, e.g. @SuppressWarnings(SonarRules.CLONE_SHOULD_NOT_BE_OVERRIDDEN)
instead of @SuppressWarnings("java:S2975").
Unfortunately, this doesn’t seem to work with constants defined in other classes.
It does work if the constant is defined in the source currently scanned, though.
I reproduced this with a simple example as shown by this screenshot using SonarLint (8.1.0.65508) with IntelliJ (2023.1 Ultimate):
Hi @fupgang,
I was able to reproduce with my IntelliJ IDEA 2023.1.1 and SonarLint 8.2.0.67892.
I need to understand if the problem comes from the java analyzer logic, or a current limitation in how the SonarLint plugin trigger analysis and provides a classpath with the most recent changes.
For example, can you confirm that the problem disappears if you go to the OtherClass.java file and select Build > Recompile 'OtherClass.java', then open Example.java and in the SonarLint panel, Current File tab, run Analyze with SonarLint (or just close and reopen Example.java)
Because in my case the issue disappears, my assumption is:
It’s a temporary problem related to constants created or modified in a file different from where the @SuppressWarnings is used
Forcing Analyze with SonarLint on Example.java when OtherClass.java has changed is not enough OtherClass.java should also be recompiled by the IDE.
Rebuilding OtherClass.java file (using Build > Recompile 'OtherClass.java' or running any test) is not enough if Example.java is still open in the IDE.
This problem always disappears once OtherClass.java has been recompiled for any reason AND a SonarLint analysis is triggered on Example.java for any reason.
So if you also have the same behavior it will stop trying to fix this false-positive (I’m working on the java analyzer) and I will assign this topic to the SonarLint team.
thank you for your analysis. I can confirm your assumption.
Whenever there is an up-to-date compiled class defining the constant in the target folder (as I’m using a Maven project) the following SonarLint analysis works as expected.
After changing the constant without recompiling, the following SonarLint analysis does neither trigger a rebuild nor give any hint that compiled classes are outdated.
So if you also have the same behavior it will stop trying to fix this false-positive (I’m working on the java analyzer) and I will assign this topic to the SonarLint team.
As this is not a problem of the java analyzer I expect SonarQube to work correctly, too.
Now I will provide a Class with constants (e.g. SonarRules.CLONE_SHOULD_NOT_BE_OVERRIDDEN) to my team.
Do you think the Sonar team could generate constants for all Java related Sonar rules with meaningful names and JavaDoc in a lightweight artifact?
Thanks for your confirmation. I will assign this topic to the SonarLint team.
About the generation of constants with Sonar’s rule keys, Sonar doesn’t provide anything related to this. And I can give you my personal opinion on this subject: Polluting the source code with information for a specific linter is a bad practice. The source code should not be coupled to a linter, a linter is a tool that should be easy to add or remove. It would be better to use some general keywords to remove warnings (like “deprecation” instead of “java:S1874”, see the conversion here). Or even better, you can report the false-positive to the linter maintainers (on this forum for Sonar) so the linter works fine out-of-the-box.
