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.
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.
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.
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.
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.
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.
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