Azure DevOps Scanner Java Incompatibility for SQ 10.4.*

SonarQube Version: 10.4.1.88267
JVM: 17.0.9+8-LTS
Java: 61.0
Hosted DevOps Scanner
Project Code: Angular (Typescript)

After Upgrading from 9.9 → 10.4, we’re encountering issues with scanning.

##[error]java.lang.UnsupportedClassVersionError: org/sonar/batch/bootstrapper/EnvironmentInformation has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0

I feel like I’m missing something, but it looks like we’re using the correct versions of Java, and being that we’re using a hosted DevOps build agent, the documentation states that it should be up to date as well.

Azure DevOps Scanner Environment

Thank you in advance!

Hi,

Welcome to the community!

It sounds like you need to upgrade the scanner too. Class file version 61 translates to Java 17, so if you’re getting an error that it’s too new, then your scanner has some age on it.

 
HTH,
Ann

Hi Ann, thanks for your help.

Our Scanner is the Azure DevOps build agent (which we’re using the MS hosted agent, not a self hosted one), and the documentation says that it should already be up to date. I don’t believe I have control over the configuration of the agent itself, so if there is something I’m missing, I’d appreciate any info you can recommend for me to research.

Quote from the SQ documentation:

All VM images available in Azure Pipelines for Microsoft-hosted agents already contain Java 17. There is no further action required.

The agent itself appears to be at version 3.236.0

As for the pipeline, we are using the SonarQubePrepare@5 task, which I believe is the current version.

Thanks again for your help.
-Joe

Hi Joe,

Would you mind sharing your pipeline code?

 
Thx,
Ann

Hi Ann,

These are the tasks that are relevant to the SonarQube process.

One other piece of info, this error is for an Angular (Typescript) application, I updated my first post with that as well.

# Prepare SonarQube for Analysis
- task: SonarQubePrepare@5
  condition: <conditions>
  inputs:
    SonarQube: '<project>'
    scannerMode: 'CLI'
    configMode: 'manual'
    cliProjectKey: $(sonarqube-cli-project-key)
    extraproperties: | 
      sonar.sources=<dir>
      sonar.tests=<test div>
      sonar.javascript.lcov.reportPaths=<report path>
      sonar.exclusions=<exclusions>
      sonar.test.inclusions=<text exclusions>
      sonar.test.exclusions=<test exclusions>
      sonar.coverage.exclusions=<exclusions>
  continueOnError: true

# Run Code Analysis task
- task: SonarQubeAnalyze@5
  continueOnError: true
  condition: <condition>

# Publish Quality Gate Result task
- task: SonarQubePublish@5
  timeoutInMinutes: 30
  inputs:
    pollingTimeoutSec: '300'
  continueOnError: true
  condition: <condition>
1 Like

Hi,

Can you try setting jdkversion: JAVA_HOME_17_X64?

It looks like we default the JVM to Java 11 because the bump to Java 17 would be a breaking change. I believe the next release will bump the default.

 
Ann

Hi Ann,

That seems to have done the trick. After specifying the JVM version in the Analyze step, the pipeline is working now.

For reference for anyone who encounters the same issue, this is how that step looks now:

# Run Code Analysis task
- task: SonarQubeAnalyze@5
  inputs:
    jdkversion: JAVA_HOME_17_X64
  continueOnError: true
  condition: <condition>

Is there an anticipated release date for the release to bump the default JVM version? I’m sure we’ll be ok with this setting for a while, but I’d like to remove the override when we are able to.

SonarQubeAnalyze@5 Documentation

1 Like

Hi,

That’s a great question, and one I’m not immediately finding an answer to.

I’m going to flag this for the team that’s responsible for that.

 
Thx,
Ann

1 Like

Hello @jmccormick

I will try to answer your questions,

Is there an anticipated release date for the release to bump the default JVM version?

We can’t just change the default value, because it would break LTS users that don’t have Java 11 installed. We will release a next major version of the tasks that will contain this change. It’s in our backlog and will happen in the following months, for sure, but is not planned yet. You can follow our internal ticket or watch the github repo if you want to be notified.

I’d like to remove the override when we are able to

This is not an override but a required input for the task. If you re-add the task, the UI will force you to specify a value for jdkversion. So having it in your pipeline definition is the expected behavior. This is reflected in our documentation and in the task definition. I would recommend to keep this input in your pipeline and not rely on the default value.

Lastly, we are pushing an update for the current task version that will auto-switch to JAVA_HOME if no value is specified for jdkversion and SQ 10.4 is detected and shows a message that explains the issue. It will hopefully make it easier for other users in a similar use-case.

I hope my answer helps

2 Likes

Hi @benjamin.raymond,

Thanks for the reply, and the reasoning is sound. I might recommend making some clarifying edits to some of your documentation to reflect that as it wasn’t entirely clear that this was a required change to make in our DevOps pipeline; specifically this page:

All VM images available in Azure Pipelines for Microsoft-hosted agents already contain Java 17. There is no further action required. For self-hosted agents, you must ensure that you are using Java 17. You can either modify your build pipeline to ensure that it runs with Java 17 by default, or override the JAVA_HOME environment variable just before running the analysis.

Re-reading it after going through this process, I see that it’s called out, but the first line states explicitly that “No further action is required”. Maybe a sentence or two about how there default Java version is 11 and you should view the documentation about the Analysis task on how to specify the usage of 17.

Anyway, my issue is resolved, and I appreciate your follow-up, thank you and @ganncamp for helping me get this addressed quickly.

2 Likes

Hello @jmccormick , thank you a lot for your feedback on the documentation page, I’ve transferred your suggestion to the documentation team and the page that you mentioned was updated online to be more accurate and consistent with the rest

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.