Run SonarQube Azure Devops Scanner using OpenJDK 17

SonarQube
1
  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    SonarQube 9.7, SonarScanner 4.7.0.2747, Azure DevOps plugins.

The Microsoft agent where I’m running the SonarQube scanner is using Java 1.8 by default, which fails the scanner execution with the following error:

##[error]java.lang.UnsupportedClassVersionError: org/sonar/batch/bootstrapper/EnvironmentInformation 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

I installed OpenJDK 17 on the build agent to use it for the scanner execution, according to the below topic link, if the JAVA_HOME_11_X64 is available, then it will be used for the analysis only, is this the same case using OpenJDK 17? For example, can I set the variable “JAVA_HOME_17_X64” and the scanner will use that version automatically?

If not, how can I select OpenJDK 17 version just for the Sonar scanner execution using the Azure DevOps plugin (Run Code Analysis)?
Right now I can not override the JAVA_HOME for the whole pipeline as there are other tasks or build that depend on Java 1.8 (Maven)

Older default java version used with Azure devops Hosted agent?

Any help or suggestion would be appreciated, thanks

3

Hi @christopher9 ,

No currently the JAVA_HOME_17_X64 variable is not supported yet. I created an entry in our backlog for this : [VSTS-294] - Jira

On your side, I think the easiest way would probably be to set JAVA_HOME to point to your java 17 installation just before the Run code analysis task, and revert it to its original value just after the analysis.
Or you can set the JAVA_HOME_11_X64 variable to point to your JAVA 17 install path, but I would not recommend this other than just for a workaround.

Would that help ?

Thanks.
Mickaël

1 Like
5

Hi @mickaelcaro

Thanks for creating the ticket to support JAVA_HOME_17_X64.

Do you have any guidance or steps to set JAVA_HOME to version 17 before the Run code analysis and revert it to the default version using pipeline tasks?

Thanks,
Christopher

6

Hi @christopher9

I don’t have out of the box example, but having a bash script before, backing up the current value of JAVA_HOME

export JAVA_HOME_BCK=$JAVA_HOME
export JAVA_HOME=/path/to/java

then doing the same the other way around after the analysis should work.

export JAVA_HOME=$JAVA_HOME_BCK

Making sure this new env variable is being picked up by the subsequent tasks also would help, sometimes there are issues with it.

HTH,

1 Like
8

Hi!
Any news on this topic?
When do you plan to ship the support for JAVA_HOME_17_X64 ?
THX

9

Hi @ArminPrieschl and @christopher9

I’m happy to share that we released a new version of the extension yesterday that is adding this support.

The Run Code Analysis now has a configurable field to let you choose which variable (or java version) you want to pick up for the analysis.

Screenshot 2023-06-15 at 07.34.32

In your case you may want to use “Use built-in JAVA_HOME_17_X64 (hosted agent)” value.

Hope that helps,
Mickaël

2 Likes