4

In SonarQube 4.5.x LTS the annotation @SuppressWarnings could be used to suppress false positives in code but after upgrading to 5.4 and re-arranging some packages these, previously suppressed, issues have resurfaced. Why?

I have been told that the recommendation from SonarSource (company developing SonarQube) is to suppress false positives from the administrative UI but we prefer to do it directly in code for reasons*. The violation below is clearly suppressed using the annotation:

Rule violation still active even though suppressed

Is @SuppressWarnings no longer handled in SonarQube?

* Reasons include:

  • No dependency on SonarQube database state
  • Not having to rely on SonarQube being able to identify an old suppressed line of code when changed)

Update (2017-02-03): SonarQube 6.x handles moving code around and keeping false positives

Alix
  • 2,630
  • 30
  • 72

2 Answers2

4

If you are using version 3.14 of the SonarQube Java Plugin, it is a known issue. The fix will be released with next incoming version (4.0). Associated JIRA ticket: SONARJAVA-1719

For older versions of the plugin (3.13.1 and before), the @SuppressWarnings annotation should work as expected and hide issue when the key of a rule is used.

Wohops
  • 3,071
  • 18
  • 29
  • Yes, I can confirm that we have version 3.14 of the Java plugin installed. This explains everything. – Alix Jun 20 '16 at 09:10
1

You can use the //NOSONAR annotation behind the line. That doesn't really resolve it, but it's a way SonarCube ignores it.

Niklas
  • 64
  • 1
  • 8
  • 1
    We consider the use of `//NOSONAR` to be a code smell as it may hide other issues that are far more severe than the false positive that we intended to suppress – Alix Jun 20 '16 at 07:44
  • @Alix Okay that's the same reason why I don't use it, I just wanted to mention it. – Niklas Jun 20 '16 at 08:26