Many new issues created after updating SonarJava to version 6.0 (with SonarScanner running in the meantime)


  • Community EditionVersion 7.9.1 (build 27448)
  • SonarJava: 6.0 (build 20538)

We have updated the SonarJava to version 6.0. After that all previously created issues of the SonarJava rules were closed (removed) and opened new. The new code part of SonarQube dashboard shows them as new.
I suppose this is because of the ID of the rules changed from “squid” to “java”.

Potential repro:

  1. SonarScanner is started on Jenkins
  2. Update SonarJava to version 6.0 on SonarQube server web UI
    (There was an analysis of another SonarScanner-run running on the SonarQube server; thus waited for end of that analysis for restarting the server)
  3. SonarQube server is restarted with SonarJava 6.0
  4. SonarScanner run is finished
  5. SonarQube server analysis is executed and creates a lot of new issues

ce.txt (295.9 KB) es.txt (314.0 KB) sonar.txt (19.1 KB)
web.txt (116.0 KB)

Another problem; related to that context: after another restart of the server both SonarJava jars (6.0 and 5.14) were still available in the “extensions/plugins” directory and thus the server did not start. Had to manually delete them to start the server correctly.

Update: Jenkins Log: SonarScanner Jenkins Log.txt (183.1 KB)

1 Like

Yes, this change of the rule key names caused a lot of confusion, after the merge of
feature (shortlived) branches to master, when @SupressWarnings(“squid:…”) has been used.
It’s already adressed with
which is hopefully released soon.

I have seen that issue (you mean ); but my problem is not related to “@SuppressWarnings” annotation in the source code.
It does affect all issues; and perhaps also the combination of updating SonarJava + concurrently running SonarScanner.

Sorry, the link i posted does only work after login to Sonarsource Jira.
I meant
After updating to SonarJava 6.0 on Sonarqube 7.9.1, i noticed the change of rule keys
only because of the Track uses of "@SuppressWarnings" rule.
The first analysis after the plugin update raised a bunch of issues for that rule.
Noticed the key rename after reading the release notes again - this should have been
more prominent. And the tests should catch those cases.
But i didn’t notice any other reappearing issues.

Had this experience only after deletion of short-lived branches and subsequent analysis of the
master branch, as there is a sync between master and short-lived branches.
Starting with Sonarqube 8.1 there is only one type of branch.

hello @Holger_Mensch,

the change of rule keys should be handled automatically on the upgrade. Also, upgrade will normally remove the previous version of the plugin. So something strange must have happened to your instance.

Do you have logs from the analysis, to check which version of java analyzer was used for it?

If possible I would avoid upgrading the plugins while there are analysis in progress, as it can lead to unpredictable behavior.

  • The Rule Keys have been changed to the new structure (“java:…”)
  • I have attached the logfile of the SonarScanner run too (see above). I cannot see from the logfile of the SonarScanner run or from the SonarQube analysis run what SonarJava version was used. Just in the sonar-Web logfile the update is mentioned: “Plugin SonarJava [java] updated to version”

If it is not allowed to upgrade the plugin during a SonarScanner run this should be at least mentioned in the documentation.

Yes, we have changed the keys of the rules in sonar-java 6.0. There is automatic mechanism which should have handled the renaming on the server start, but for some reason it has failed in your case. It would be hard to determine what happened, because we don’t know which version of plugin was used for the analysis.

I would suggest the following:

  • back-up your database, just to be sure to be able to go back
  • downgrade the sonar-java plugin to the previous version (5.14)
  • run analysis
  • issues should be restored to their previous state
  • upgrade the plugin to 6.0 (you can wait for bugfix 6.0.1 to fix issue with SuppressWarnings if you use that feature)
  • run analysis
  • issues should have their rule keys renamed and state should not change

I am taking the point on updating the documentation. And sorry for this inconvenience.