Scanner-cli 7.2 bundled JRE is Java 17 — fails against SonarQube Cloud's Java 21 requirement

SonarQube Cloud
1

Hi,

After the July 20, 2026 cutover requiring Java 21+ for SonarQube Cloud analysis, our GitHub Actions CI scans started failing with:

  ERROR Java 17 is not supported. Please upgrade to Java 21 or newer, or use
  JRE auto-provisioning to keep this requirement always up to date.

We use sonarqube-scan-action v7 with -Dsonar.scanner.skipJreProvisioning=true. The log shows the scanner falling back to the JRE bundled with sonar-scanner-cli 7.2.0.5079, which is Java 17:

  Using the java executable '.../sonar-scanner-cli/7.2.0.5079/linux-x64/jre/bin/java' from JAVA_HOME

So with JRE provisioning skipped, the scanner runs on a bundled Java 17 that SonarQube Cloud now rejects.

Questions:

  1. Is it expected that scanner-cli 7.2 still bundles a Java 17 JRE, given Cloud now requires 21+? Is there a scanner-cli version that bundles 21?
  2. For environments that must set skipJreProvisioning=true (e.g. private/firewalled CI runners that can’t download the JRE from Cloud), what’s the recommended way to supply a Java 21 runtime to the scanner? Is setting JAVA_HOME to a separately-installed JDK 21 before the scan the intended path?
  3. Any guidance on the tradeoffs between enabling auto-provisioning vs. pre-installing Java 21 for locked-down runners?

Environment:

  • sonarqube-scan-action v7
  • sonar-scanner-cli 7.2.0.5079
  • Target: SonarQube Cloud
  • Runners: firewalled/private, limited outbound network
2

Yes. The embedded JRE was upgraded to 21 in SonarScanner CLI v 8.0.

  1. For environments that must set skipJreProvisioning=true (e.g. private/firewalled CI runners that can’t download the JRE from Cloud), what’s the recommended way to supply a Java 21 runtime to the scanner? Is setting JAVA_HOME to a separately-installed JDK 21 before the scan the intended path?

Yes. That’s correct.

Any guidance on the tradeoffs between enabling auto-provisioning vs. pre-installing Java 21 for locked-down runners?

If you have many pipeline runners, you’ll need to install Java 21 on all of them, and then remember to upgrade in the future when SonarScanner / SonarQube Java requirements change. With JRE auto-provisioning, you don’t have to manage the JRE used to run SonarScanner – you can ‘set it and forget it’. That’s the tradeoff.

3

Hi Austin,

My bad, I didn’t realize the sonarqube-scan-action v8 was available. I appreciate the help.