@Dorian_Burihabwa I was wondering, what are the breaking changes in Sonar Scanner for Maven v5? The release notes from last November don’t list any. Yet, it’s a new major version.
Our IT folks upgraded the old 9.9 LTA installation to community v25.6 and this ended Java 11 support. Even though the error message suggests there may be an incompatibility issue with the scanner plugin itself, it’s actually the server that doesn’t support Java 11 anymore AFAIU.
[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar (default-cli) on project modules-customization-module: Execution default-cli of goal org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar failed: An API incompatibility was encountered while executing org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar: java.lang.UnsupportedClassVersionError: org/sonar/batch/bootstrapper/EnvironmentInformation has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
Since we’re currently still using the latest v4 Maven plugin I first thought we needed to bump it to v5, and that’s when I started wondering about its breaking changes.
Hi @marcelstoer,
what are the breaking changes in Sonar Scanner for Maven v5? The release notes from last November don’t list any. Yet, it’s a new major version.
You are correct, the breaking changes are not listed properly. It is a known problem that we plan to address in the future.
The breaking change is essentially that version 5 of the scanner introduces the new bootstrapping mechanism. This mechanism ensures that while users are supposed to trigger the analysis of their project using Java 11 or 17 with the Maven plugin, they should not have to concern themselves with the bootstrapped runtime for analysis (ie: if we plan to move our analysis stack to Java 21 or 25, it should not impact you in the future). The short version of it all is that we embed an appropriate JRE in you SQ instance that will be auto provisioned by default for the analysis (see how you can play around with the analysis parameters if the defaults are not suitable for you).
Our IT folks upgraded the old 9.9 LTA installation to community v25.6
The analysis stack has switched to Java 17 during the 10.x cycle, to minimize your pain, you should give version 5+ of the Maven scanner a try.
PS: Please refrain from pinging people directly. That is not great form.
Thanks for the detailed explanation.
How about just adding a “Breaking Changes” section (just like “Documentation”)? AFAIU the sonar.host.url is a potentially breaking change i.e. breaking only for on-prem installations. Likewise, the JRE provisioning is only an issue if the scanner runtime environment defines a JRE different from what the scanner would auto-provision?
PS: Please refrain from pinging people directly. That is not great form.
Sorry, I didn’t know this community considers it bad form. The intention was to direct my question to the release notes author specifically.
AFAIU the sonar.host.url is a potentially breaking change i.e. breaking only for on-prem installations.
Indeed, if you don’t have the url specificed in your configuration, sonar.host.url defaulting to SQC is big change (thankfully, it is easy to diagnose and fix).
Likewise, the JRE provisioning is only an issue if the scanner runtime environment defines a JRE different from what the scanner would auto-provision
If we have done our work correctly, you should not experience any problem there. We still read the language version from the build configuration and we match the Java API used in the project against the the version of Java that used to invoke the scanner.
In practice, if my project is built using with Java 11, and I then run mvn sonar:sonar still using Java 11, the Java analyzer recovered through the bootstrapping will run using Java 17, but will match the code of my project against Java 11 (ensuring I get the proper deprecation warnings).