SonarCloud raises error on old code after merging upgrade to java 17

This one is a bit specific.

We use SonarCloud, and the “New Code” settings for the relevant project is as following:

I.e, on the main branch, only code newer than 2 days is considered.

We had a merge request that made some changes, including switching from Java 11 to Java 17. It had a passing pipeline, so we merged, and bam! the analysis fails on the main branch:

As you can see, the new code is correctly detected (it says “New code: Since 2 days ago”, and only 9 lines are considered as new. However, I get 10 code smells, and they are raised on totally different and much older code. Those smells are typically related to Java 17 (Replace this usage of ‘Stream.collect(Collectors.toList())’ with ‘Stream.toList()’).

So my question is: Does SonarQube ignore the new code definition when it’s detecting a java version change? Is it because those issues are on old code but are considered new? And why was it not raised in the passing merge request analysis?


Hey there!

I just want to double check – did you only change the version of Java running the scanner, or also start compiling to Java 17 bytecode?

I changed the java target version in the maven POM, so that it automagically uses a JDK 17 for building!

Thanks. This is a tricky situation where issue backdating doesn’t kick in.

  • On the first analysis of a project or branch
  • When the rule is new in the profile (a brand new rule activated or a rule that was deactivated and is now activated)
  • When the analyzer has just been upgraded (because rule implementations could be smarter now)
  • When the rule is external

The rule is technically not new to the profile or smarter, its logic just figures out that it should raise an issue (as it always would have) because Java 17 is being used.

I hope you can forgive us those 10 issues this time, and I’ll flag this for attention by moving it to the Producrt Manager for a Day category.


To be perfectly straight, I find this awesome. I don’t mind putting out another MR to fix this, it’s 10 code smells out of our codebase. I just wanted to understand the inner workings and find some documentation.

Thank you!


I agree! And, wouldn’t it be great if those issues had been found during the PR that changed the target Java version? That would be something this roadmap feature would address: