Part of

Description

The Guava ruling passed -Djava.version=17 to both its compilation and scanner goals. Scanner Engine 13.3 and newer interprets that Maven property as the scanner runtime version and rejects it, even though Maven is already running on Java 21.

Limit the Java 17 override to Guava compilation and run the scanner goal with the actual Java 21 runtime version.

Root cause

The ruling workflow already selects Java 21, and the failing job confirms that Maven runs from a Java 21 runtime. The failure is caused by a property collision rather than by selecting a Java 17 installation:

• The Guava POM uses its java.version property as the compiler source and target level.
• The ruling test overrides it with -Djava.version=17 so Guava is compiled as Java 17 code.
• Maven exposes that user property as java.version to the in-process scanner.
• Scanner Engine 13.3 and newer uses that property to validate its runtime and therefore believes that it is running on Java 17.

This became visible when LATEST_RELEASE changed from SonarQube 2026.3.1 with Scanner Engine 12.30.0, which only warned, to SonarQube 2026.4 with Scanner Engine 13.4.1, which rejects scanner runtimes below Java 21.

Why compilation and scanner runtime remain separate

The SonarQube change ends support for running the scanner JVM on Java 17. It does not end support for analyzing projects whose source or bytecode targets Java 17. Keeping Guava compiled for Java 17 preserves ruling coverage for Java 17 projects, while running the scanner itself on Java 21 satisfies the new runtime requirement.

Removing Java 17 from mise.toml would not fix this failure. That file makes several JDKs available, while the workflow explicitly selects Java 21. The misleading Java 17 value comes from the Maven property passed to both goals.

Moving Guava compilation to Java 21 would also avoid the failure, but it would intentionally drop this Java 17 analysis coverage and could change ruling results. That should be a separate support-policy decision rather than an incidental consequence of the scanner runtime upgrade.

Fix

• Apply -Djava.version=17 only to the Guava clean package goal.
• Append Orchestrator's canonical scanner goal so scanning runs as a separate Maven invocation without the java.version override. The goals use a mutable ArrayList because Orchestrator's varargs setGoals() creates a fixed-size list that addSonarGoal() cannot append to.
• Set sonar.java.source=17 explicitly. Once compilation and scanning are separated, the scanner otherwise reads Guava's original Java 8 POM setting, which changes rule behavior and produced 1,482 ruling differences. This property preserves the existing Java 17 analysis semantics without misrepresenting the scanner JVM runtime.

Validation

• mvn -pl its/ruling -am -DskipTests test-compile on Java 26
• Ruling QA without-sonarqube-project on Java 21 with SonarQube LATEST_RELEASE
  • Guava compilation runs separately with -Djava.version=17.
  • The scanner invocation has no java.version override and reports Java 21.
  • Analysis reports sonar.java.source=17 and no ruling differences.