We are currently using SonarQube 9.9.6 Enterprise Edition and recently received a notification that this version is no longer active. We are planning to upgrade to the latest Long-Term Active (LTA) version, but we’ve encountered some challenges and would appreciate your guidance.
Our current setup is as follows:
SonarQube Server: 9.9.6 Enterprise Edition (now upgraded to Java 17)
Build Agents: All running Java 11
Applications: Built with Java 11
Upgrade Target: Latest LTA version (from 9.9.6)
Issue: Java version mismatch errors during upgrade attempts
We understand that newer SonarQube versions require Java 17 for the server, and we’ve already upgraded the server accordingly. However, since our build agents and applications are still on Java 11, we want to ensure compatibility before proceeding further.
We’d like to confirm the following:
Can we continue analyzing Java 11 applications using agents that run Java 11, while the SonarQube server runs on Java 17?
Is it sufficient to configure sonar.java.jdkHome in the scanner to point to the Java 11 JDK used for compilation?
Is SonarQube 2025.1 the current LTA version, and does it support this setup?
We’re also transitioning from the regular release track to the LTA release track, so any best practices or migration tips would be greatly appreciated.
The SonarScanners require Java 17 to run the analysis. So, your agents should have Java 17 configured. If your project requires compilation with Java 11, you can use the sonar.java.jdkHomeproperty to point to a Java 11 installation.
And yes, this configuration is supported in SonarQube v2025.1 LTA.
Additionally, please review the list of supported database versions to ensure compatibility. You may need to upgrade your database if it’s not supported.
To clarify, the sonar.java.jdkHome property in SonarQube is used to specify the JDK that should be used for analyzing and compiling your Java project source code. However, it does not change the Java version used to actually run the analysis process itself; that JVM must still meet SonarQube’s requirements. This property matters if your code depends on a different JDK version than what’s used to launch the scanner, as it determines how the code is parsed and which issues might be detected during analysis.
All of that said – with JRE auto provisioning, upgrading SonarQube becomes much easier. The latest versions of the scanners automatically download and use a compatible JDK from your SonarQube server (when hooked up to a version that supports JRE auto-provisioning, like 2025.1 LTA), so you no longer need to manually upgrade Java on all your environments. Simply ensure you are using the most recent version of each scanner.
Is the root cause of these errors solely due to the SonarQube version being inactive, or could there be other network or configuration issues involved? The server is running and reachable via browser, but the tasks in Azure DevOps fail during the SonarQubePrepare step.
Any guidance on whether upgrading SonarQube will resolve these issues or if additional troubleshooting is needed would be greatly appreciated.
