Hi everyone!
Just confirming, will SonarCloud just stop supporting it, or we can´t be able to use Java11 to run the Scanner? (In that case, what´s gonna be the “response” when we use the scanner with Java11)
We saw the bump on CircleCI Orb Version (sonarsource/sonarcloud@2.0.0) we are testing because in some projects we still receiving the message about the Java Version using the (sonarcloud: sonarsource/sonarcloud@1.1.1).
Hi Alex,
How correct is the following assumption:
If i update my SQ server instance to 10.2, i will still be able to use java 11 as runtime, because deprecation is to be interpreted as “marked for removal” and the removal is expected to be included in 10.3 or later updates.
cheers
Daniel
@daniel When you will update to SonarQube 10.2, you will still be able to use Java 11 as a runtime if you change nothing on your CI configuration. If you update the Scanner CLI to the 5.x, then you will need to install a Java 17 runtime.
@rafael-loggi SonarCloud will, after the 31st of October 2023, not allow you to trigger scans if you still use Java 11 as a runtime. It will just fail at the beginning saying that the JRE version used is not supported. You will get a java.lang.UnsupportedClassVersionError error.
Hi Alex, thank you for clarifying.
Is there maybe something you might be able to share about the roadmap for gradle or maven plugins which wrap the scanning in those build tools?
I’ll double-check internally and get in touch with TravisCI if needed
Hi @Alexandre_Gigleux - I just wanted to check if there was any update at all as to whether this was a Sonar thing or a Travis thing? Happy to contact Travis directly if that is of any use? Thanks in advance!
@EdWade This is a TravisCI thing. I tried to find a way to contact someone at Travis CI but I ended up creating this issue. If you can push on your side, that will help.
@daniel Unless we missed something, there is no plan to release a version for the Scanner for Maven or Gradle related to this Java 11 deprecation notice. You can already install a Java 17+ runtime on your scan machine and it will work. May I suggest that you open a dedicated thread to discuss this topic if you believe it is necessary?
@Alexandre_Gigleux So it means running the maven scanner will continue to work on Java 11 runtime ?
I mean for now (as example) it’s not possible to use the 3.9.1.2184 to scan Java 8 project using same Java 8 runtime (We need to change JDK to run the sonar goal. Explained here : Moving Analysis to Java 11
So what the difference with Java 11 deprecation ? Will be the same ? Java 11 project should change their runtime to to Java 17 ?
Thanks for your details
There is no difference with the Java 11 deprecation. You have to apply the same actions you did for the Java 8 to Java 11 move: split the “build” and the “sonar” phase so they use a different Java runtime.
You can and probably should do that now to be ready to move to the next versions of SonarQube.
Thanks @Alexandre_Gigleux is clear now
We are using SonarQube plugin (v2.14) in our Jenkins for scanning our non-java projects. Could you clarify if the plugin needs to be upgraded for the Java11 deprecation? or can we continue with the same plugin version without any impact?
Also, will there be any impact for sonar-maven plugin with locked <=3.9 version
The change is about how you run analysis, not (necessarily) about how you run Jenkins.
And BTW, you might want to upgrade to the current version of the Jenkins plugin: 2.16.
HTH,
Ann
Thanks for clarifying the Jenkins plugin version.
As for the sonar-maven plugin, is there any specific version of the plugin that requires Java17 for the analysis?
Hi,
Version 3.10 supports Maven 4, so I suspect you’ll need to upgrade Java with that (altho TBH, I’m not sure).
But it’s mostly about your SonarQube version. Please start a new thread if you have further questions.
Thx,
Ann
A post was split to a new topic: When do you plan to support the Java 21 LTS for the sonar-maven-plugin?
Hello,
I’m coming back with some updates. We identified that there are still 25% of SonarCloud’s projects that rely on Java 11 to trigger their code scan. This is not good enough to pull the trigger and stop the support of Java 11. This is why we moved the end of support date to the 15th of November.
If you are impacted, a message is now displayed on the top of each project using Java 11 and an email will reach your inbox in the coming hours to make sure you are aware of this.
Please, update your pipelines and use Java 17+ runtime env to trigger your scans.
Regards
Alex
Hello,
We currently use SonarCloud, and most scanners use the Sonar Scanner Plugin for Maven and Gradle.
You should continue to use the current versions of the SonarScanner Plugin for Maven and Gradle. What you need to change is the JRE that is used to run these scanners.
Basically, if you type java -version and you see Java 11 and not something like the following, then you need to install a JRE 17+ and make sure it is in your PATH:
OpenJDK Runtime Environment Temurin-17.0.8+7 (build 17.0.8+7)
OpenJDK 64-Bit Server VM Temurin-17.0.8+7 (build 17.0.8+7, mixed mode)
Alex
Sorry, I don’t understand, why are you doing that.
Public available LTS support for Java 11 ended less than one month ago. Oracle is supporting Java 11 as part of extended support until 2032(!). We are developing for Weblogic 14c environment. It doesn’t support Java 17 as runtime currently.
Your requirement (announced here in Juli 2023) to migrate to Java 17 during next 3 months looks like a chicanery in my eyes.
I don’t get what you mean by “chicanery”.
Our policy is to support only the 2 latest LTS JRE as a runtime to trigger the code scan. We have a similar policy for NodeJS env requirement. Java 21 was released in Sept 2023, so it implies that we support only Java 17 and Java 21 LTS as a runtime env.
The fact you are developing for “Weblogic 14c environment which doesn’t support Java 17” has no link with our requirements to run SonarQube or the SonarScanners. On your CI machines, you have to install a JRE 17 to run the sonar scanners and you can still continue to compile your code for Java 11.
If you are using SonarQube 9.9 LTS, you have nothing to change. It’s only when you will move to 10.x LTS that you will have to find a way to run the scans with JRE 17.
I hope it helps.