# General requirements {% hint style="warning" %} We do not recommend running an antivirus scanner on the machine where a SonarQube Server analysis runs, it could result in unpredictable behavior. {% endhint %} ## Operating system The supported operating systems are: * Linux (x64, AArch64). * Windows (x64). * macOS (x64, AArch64). Note: z/OS is not supported. ## Java runtime environment (JRE) A JRE (Open JRE or Open JDK) is required for the scanner engine used by all SonarScanners. The required JRE can be auto-provisioned by a scanner at analysis time. Depending on your SonarScanner, JRE may be auto-provisioned. JRE auto-provisioning is currently supported by: * SonarScanner CLI, from version 6.0. * SonarScanner for .NET, from version 7.0. * SonarScanner for NPM, from version 4.0. * SonarScanner for Maven, from version 5.0 * SonarScanner for Gradle, from version 6.0 See [#if-jre-auto-provisioning-is-not-supported](#if-jre-auto-provisioning-is-not-supported "mention") for actions you may need to take if JRE auto-provisioning is not supported. ### Required Java versions Following are the minimum Java versions required on your CI/CD host depending on your context. | Scanner | Enabled JRE auto-provisioning | Disabled JRE auto-provisioning | | ----------------------- | ----------------------------------------------------------------- | ------------------------------------- | | SonarScanner for Maven | Java 11 | Java 21, Java 17 has been deprecated. | | SonarScanner for Gradle | Java 11 | Java 21, Java 17 has been deprecated. | | SonarScaner CLI |

Java 11 (from version 7.2)
Java 17 (before version 7.2)

| Java 21, Java 17 has been deprecated. | | SonarScanner for .NET | None | Java 21, Java 17 has been deprecated. | | SonarScanner for NPM | None | Java 21, Java 17 has been deprecated. | | SonarScanner for Python | None | Java 21, Java 17 has been deprecated. | {% hint style="warning" %} **Deprecation note**: Java 17 is deprecated as a supported scanner runtime environment and its support ends with SonarQube Server 2026.3 (July 2026), SonarQube Community Build and SonarQube Cloud in July 2026. There is no impact for this change if you use JRE auto-provisioning, enabled by default on scanners that support it, because it keeps Java version requirements always up to date. If you disabled JRE auto-provisioning or your scanner doesn’t support it, you need to update to Java 21 or newer. {% endhint %} Additional requirements may exist for specific scanners or languages. Check the respective SonarScanner and language pages for more details. In particular, to analyze JavaScript, TypeScript, or CSS, additional requirements exist, see [javascript-typescript-css](https://docs.sonarsource.com/sonarqube-server/2025.2/analyzing-source-code/languages/javascript-typescript-css "mention"). {% hint style="info" %} * The requirement on the JRE refers only to the version of Java used by the scanner itself to run. It does not restrict the versions of Java that can be analyzed by the scanner. In addition, the required version changes with successive versions of the scanner. * In rare cases, you may want to disable the auto-provisioning. To do so, set the `sonar.scanner.skipJreProvisioning` to `true`. See [#jre-autoprovisioning](https://docs.sonarsource.com/sonarqube-server/2025.2/analysis-parameters#jre-autoprovisioning "mention") for more information. {% endhint %} ## If JRE auto-provisioning is not supported This section describes the actions you may need to take depending on your environment in order to make sure the required Java version is used for the analysis. ### GitHub Actions The GitHub Action for SonarQube Cloud can be configured for different target build technologies. You can find samples for .NET, Gradle, Maven and a generic one, all running with JDK11 [here](https://github.com/SonarSource/sonarcloud-github-action-samples). {% hint style="info" %} If you follow these examples, we recommend using the minimum recommended version mentioned at the top of this page. {% endhint %} ### ### Maven / Gradle If your whole Maven or Gradle build doesn’t run on Java 17, we suggest first trying to base the whole build on this version of Java. If it’s not compatible, then you can override the `JAVA_HOME` environment variable just before the analysis step, as shown here: ```css-79elbk # Maven build mvn verify ... export JAVA_HOME=/path/to/java-17 mvn org.sonarsource.scanner.maven:sonar-maven-plugin:sonar ... ``` ```css-79elbk # Gradle build gradle build ... export JAVA_HOME=/path/to/java-17 gradle sonar ... ``` ### Azure DevOps All VM images available in Azure Pipelines for Microsoft-hosted agents already contain Java 17. You need to ensure your build pipeline uses the correct JDK version (`JAVA_HOME_17_X64`). For self-hosted agents, you must ensure that you are using Java 17 by modifying your build pipeline to use `JAVA_HOME` and override the `JAVA_HOME`environment variable just before running the analysis. **Xamarin** For the specific case of Xamarin, which only allows Java 8, you will need to specify a Java 8 path separately when invoking MSBuild (using, for example, `XAMARIN_JAVA_HOME`), and then leave the `JAVA_HOME` environment variable for the scanner only. ```css-79elbk $env:JAVA_HOME=/path/to/java-17 $env:XAMARIN_JAVA_HOME=/path/to/java-8 msbuild.exe /p:JavaSdkDirectory=$env:XAMARIN_JAVA_HOME ``` ### Dockerfile Multiple base images can be used to run your build with Java 17, here are some examples: * `openjdk:17-jdk-slim` * `gradle:8.10.0-jdk17-jammy` If your build is not compatible with Java 17, then you can override the `JAVA_HOME` environment variable to point to Java 17 immediately before running the analysis. ### Jenkins You can define a new JDK in **Manage Jenkins > Global Tool Configuration**, if you have the [JDK Tool Plugin](https://plugins.jenkins.io/jdk-tool/) installed. **Declarative pipelines** If you are using a declarative pipeline with different stages, you can add a ‘tools’ section to the stage in which the code scan occurs. This will make the scanner use the JDK version that is specified. ```css-79elbk stage('SonarQube analysis') { tools { jdk "jdk17" // the name you have given the JDK installation in Global Tool Configuration } environment { scannerHome = tool 'SonarQube Scanner' // the name you have given the Sonar Scanner (in Global Tool Configuration) } steps { withSonarQubeEnv(installationName: 'SonarQube') { sh "${scannerHome}/bin/sonar-scanner -X" } } } ``` If you are analyzing a Java 11 project, you probably want to continue using Java 11 to build your project. The following example allows you to continue building in Java 11, but will use Java 17 to scan the code: ```css-79elbk stage('Build') { tools { jdk "jdk11" // the name you have given the JDK installation using the JDK manager (Global Tool Configuration) } steps { sh 'mvn compile' } } stage('SonarQube analysis') { tools { jdk "jdk17" // the name you have given the JDK installation using the JDK manager (Global Tool Configuration) } environment { scannerHome = tool 'SonarQube Scanner' // the name you have given the Sonar Scanner (Global Tool Configuration) } steps { withSonarQubeEnv(installationName: 'SonarQube') { sh 'mvn sonar:sonar' } } } ``` This example is for Maven but it can be easily modified to use Gradle. **Classical pipelines** **Set Job JDK version** You can easily set the JDK version to be used by a job in the **General** section of your configuration. This option is only visible if you have configured multiple JDK versions under **Manage Jenkins** > **Global Tool Configuration**. **Set ‘Execute SonarQube Scanner’ JDK version** If you are using the **Execute SonarQube Scanner** step in your configuration, you can set the JDK for this step in the configuration dialog. By using this approach, you can use JDK 17 only for the code scanning performed by SonarQube. All the other steps in the job will use the globally configured JDK. **Java 11 projects** Jenkins does not offer functionality to switch JDKs when using a **Freestyle project** or **Maven project** configuration. To build your project using Java 11, you have to manually set the `JAVA_HOME` variable to Java 17 when running the analysis. To do this use the [Tool Environment Plugin](https://plugins.jenkins.io/toolenv/). This plugin lets expose the location of the JDK you added under **Manage Jenkins** > **Global Tool Configuration**. The location of the JDK can then be used to set the `JAVA_HOME` variable in a post-step command, like this: ```css-79elbk export JAVA_HOME=$OPENJDK_17_HOME/Contents/Home mvn $SONAR_MAVEN_GOAL ```