SonarQube Analysis Failing on Jenkins Pipeline Due to Java 8 Incompatibility – Need Help with Dynamic Java Version Switching

[martinluther]

Problem Description:

I am facing an issue where my Jenkins pipeline fails during the SonarQube (version 9.9) analysis. The pipeline runs on a Jenkins agent machine with Java 8, but the SonarQube plugin requires Java 11, which is causing the job to fail with the following error:

vbnet

Copy code

[ERROR] Failed to execute goal org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar (default-cli) on project MyProject: 
Execution default-cli of goal org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121:sonar failed: 
Unable to load the mojo 'sonar' in the plugin 'org.sonarsource.scanner.maven:sonar-maven-plugin:4.0.0.4121' due to an API incompatibility: 
org.codehaus.plexus.component.repository.exception.ComponentLookupException: org/sonarsource/scanner/maven/SonarQubeMojo has been compiled by a more recent version of the Java Runtime 
(class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

---

Setup:

• Jenkins Version: 2.x
• SonarQube Version: 9.9 (running on Java 17)
• Jenkins agent: Running Java 8

---

What I’ve Tried:

• Alternative agent with Java 8 and Java 11 Installed: I also tried running the job on another Jenkins agent that has both Java 8 and Java 11 installed (Java 11 being the default). However, I faced the same issue when attempting to run the SonarQube analysis on that agent.

Here is part of the log from the failing pipeline:

ruby

Copy code

14:13:19  [INFO] --- sonar-maven-plugin:4.0.0.4121:sonar (default-cli) @ MyProject ---
14:13:19  [INFO] Downloading: https://artifactory.example.com/repository/xyz/org/sonatype/plexus/plexus-sec-dispatcher/1.4/plexus-sec-dispatcher-1.4.pom
14:13:19  [INFO] Downloaded: https://artifactory.example.com/repository/xyz/org/sonatype/plexus/plexus-sec-dispatcher/1.4/plexus-sec-dispatcher-1.4.pom (3 KB at 160.6 KB/sec)
14:13:19  [WARNING] Error injecting: org.sonarsource.scanner.maven.SonarQubeMojo
14:13:19  java.lang.TypeNotPresentException: Type org.sonarsource.scanner.maven.SonarQubeMojo not present
14:13:19  	at org.eclipse.sisu.space.URLClassSpace.loadClass(URLClassSpace.java:147)
...
14:13:19  Caused by: java.lang.UnsupportedClassVersionError: org/sonarsource/scanner/maven/SonarQubeMojo has been compiled by a more recent version of the Java Runtime (class file version 55.0), 
this version of the Java Runtime only recognizes class file versions up to 52.0
14:13:19  	at java.lang.ClassLoader.defineClass1(Native Method)
...
14:13:19  [INFO] BUILD FAILURE

---

Questions:

1. Is there a way to dynamically switch Java versions in a Jenkins pipeline so that I can use Java 8 for regular builds but Java 11 for SonarQube analysis, without causing compatibility issues with other jobs that depend on Java 8?
2. What are the best practices to configure a Jenkins setup that requires different Java versions for specific tools like SonarQube?
3. Has anyone encountered similar issues where SonarQube requires Java 11, but the Jenkins agent defaults to Java 8? How did you manage to resolve it?

---

Additional Context:

• SonarQube: Runs on a separate instance with Java 17.
• Jenkins agent: Java 8, with another agent available that has both Java 8 and Java 11 installed.
• Sonar Maven Plugin: 4.0.0.4121

Any insights or suggestions would be greatly appreciated. Thanks!

[dduportal (Damien Duportal)]

Hi @martinluther , there are multiple methods to change dynamically during a pipeline execution.

• First uses the “Jenkins Tool” which will download a JDK on each build. YOu have an initial configuration step as admin: go to “Manage Jenkins → Tools (in the System configuration area) → Click on the “JDK Installations” to expand”. From here, you will have to setup a collection of JDKs with the expected versions and installation methods (direct download from archive, shell script, bat script for Windows, etc.).
  Then you can use the pipeline step tool to tell Jenkins to install the specified JDK and use it:

stage('Build') {
    withEnv([
        "JAVA_HOME=${tool 'jdk11'}",
        'PATH+JDK=$JAVA_HOME/bin',
    ]) {
            if (isUnix()) {
                sh command
            }
            else {
                bat command
            }
        }
    }
}

Example at custom-war-packager/Jenkinsfile at a7c94fa271ca7084acad725f4799944573a65dbf · jenkinsci/custom-war-packager · GitHub

(scripted pipeline works the same way: pipeline-library/vars/infra.groovy at 8558c96ec6fc26625e0a4af36d2b1c2d97e5bec2 · jenkins-infra/pipeline-library · GitHub)

Example of admin configuration on the public ci.jenkins.io Jenkins:

• The other alternative (which can co-exist with tools with no issues) is to install multiple JDKs in your agent machine (or templates if you use ephemeral agents) and set up the JAVA_HOME and PATH to use the JDK of your liking. Each agent configuration can specify a custom Java binary for spinning up the agent (which should be the same JDK version as the controller!) while specifying another JDK for users in their jobs.
  This technique is really efficient to allow the Jenkins administrators to use recent JDKs quickly without impacting their users who need older JDKs.
  See the permanent agent configuration on ci.jenkins.io which needs JDK17 for running the agent, but specifies JDK11 for pipelines users:

In your case, with the 2nd method, you will have to use the same pipeline technique using the withEnv([]) {} method to run your SonarQube steps with the JDK of your liking.

---

=> I recommend you to start with the 2nd method to allow your setup to be ready for the upcoming JDK11 depreciation for running Jenkins (end of October). It will allow your admins. to quickly start using JDK17 or even JDK21 for running Jenkins and its agents while keeping JDK8 and JDK11 for your users.

[sodul (Stephane Odul)]

See this related post, it might help with your use case.

Unable to connect to SonarCloud

We gave up in the Sonar plugin as it was not working as intended, including crashing the pipelines IIRC. Instead we just embed Sonar Scanner into our CI container and call it as a regular process. This has worked well for us for the past 5 years. The ‘downside’ is that we need to pass the sonar token explicitly to the step, but we are going to address that by writing a custom step that will get the creds and call the scanner in one line. Note that for SonarCloud the Scanner does require JRE 17…

[martinluther]

Hi @dduportal,

Thanks for your reply.

My Jenkins slaves are running in separate AWS instance in docker container i have 2 slaves one is Java 8 agent for java 8 project pipeline only install Java 8 version another one is Java 11 default and also java 8 is installed in that same agent total 2 slaves. So the think is i try to run the java 8 Jenkins pipeline for java 8 project built it failed because of SonarQube 9.9 plugins does n’t run in java 8 agent SonarQube need at least java 11 so my question is that possible to run the same pipeline groovy script. can we configure java 8 for maven build and other think java 11 for only SonarQube 9.9 after complete the SonarQube analysis again return continue on java 8 is that Possiable or Not.

Regard,
Martin