October 2020 - Move to Java 11: The version of Java installed in the scanner environment should be upgraded to at least Java 11 by October 2020. Pre-11 versions of Java are already deprecated and scanners using them will stop functioning after October 2020. This refers specifically to the JDK or JRE installed and used in the context where your SonarCloud scanner analysis tool is running. This may be your local build environment or your CI service.
Similar to the question asked in SonarQube 8 LTS and Java 8 - #2 by Colin , I am curious why SonarCloud is forcing scanning systems to use Java 11 this October. Java 8 is a long term supported release of Java that is rumored to be kept patched via the OpenJDK until 2025 (or later). I totally get that everyone wants to push their own code forward, but I’m curious why a pattern could not be put together to continue to allow scans with Java 8 even as many newer versions are released - I’m even okay (though not thrilled) if my code scans with Java 8 aren’t as complete or comprehensive as the “up-to-date” scanner that uses Java 11+.
But the wholesale forcing of clients to only do scans with Java 11 will cause a bunch of problems. My biggest one today is that my SonarCloud scans are run by TravisCI while it is building my code, so in essence I could maybe do the scan with Java 11 if I did a totally separate build just for Sonar with Java 11 with advanced TravisCI features or a different toolset. In any case, a bunch of work on my part.
I’d point out that Java 8 is still the version in use by much of the community - 83% last year according to JetBrains. If we are forced to use Java 11 for scans, we’ll have to analyze whether the cost of modifying our CI/CD pipelines is worth it, or maybe we just pay for less Lines of Code and lose some of our analysis of our code base. Can someone explain better the justification for this ultimatum?
You do not have to define a totally separate build, you can have two Java versions available in one build environment. We only require the scanner to be launched with Java 11, the rest of your build process can still use Java 8 in the same environment.
Hello @Rick-at-KUBRA,
The discussion was about SonarCloud. Does the cut-off date also apply to on-premise SonarCloud scanners?
I didn’t find a hint in the online documentation. If there is one, I would be glad if you can share it.
Best Regards,
Matthias
When using the Gradle sonarqube plugin one would either require a forked environment or running the scan in a different session, separate from the report generators.
Eiher case, it would be great if the Sonarqube plugin documentation included recipes on how to setup the build to make it work with Java8/Java11 after Oct 2020.
I maintain a Gradle plugin that works as a facade over the Sonarqube plugin https://kordamp.org/kordamp-gradle-plugins/#_org_kordamp_gradle_sonar
Developers that use this facade will have multiple setups and it’s likely one of them will have to keep running the build with Java 8.
As I see it, SonarSource changed the rules of the game (for good reasons). As the makers and maintainers of both Sonarcloud and the Gradle Sonarqube plugin I think it falls into their responsibility to provide usage recipes. So far the ones found in the examples assume the build and the analyzer both run with Java 11 or later. There are no recipes for keeping the build in Java 8 while running the analyzer with Java11+.
Thanks for the detailed reasoning @TomVanBraband! We appreciate it. We’ll do what we can to make our old projects run analysis with Java 11 to make this work.
We made some improvement on our documentation, especially one new page explaining for some build technologies how you can migrate from Java 8 to 11 for the analysis.
Thank you for the update. This may work for some builds but not for all. AFAIK the chosen JDK is part of the cached inputs by Gradle, changing it for a second pass will execute tasks that you may expect to be up-to-date. JavaFX projects will definitely break as there are binary changes since JavaFX 9.
It’d be great if there was a way to run the sonarqube task in fork mode so that a single build session (and not 2 as suggested) may be used.
Its not possible to use sonarqube.dependsOn("test").remove() since removal of a dependent task on a task instance is not allowed.
My only solution so far is to run JUnit tests and JaCoCo and then run sonarqube with -x, passing all the dependent tasks that I want skipped and also pass the -Dorg.gradle.java.home argument pointing to JDK 11. An initial test run of this solution seems to “work” but I am not sure what other tasks will need to be skipped or even if this is valid.
Here is some example code where “$module” is any module in a multimodule Android project in Android Studio:
// Run jacocoTestReport which runs JUnit tests and outputs the JaCoCo XML file
sh "./gradlew $module:clean $module:jacocoTestReport"
// Now run sonarqube with JDK 11 and skip the dependent tasks leaving it just to read the JaCoCo XML file
sh """
./gradlew -Dorg.gradle.java.home=$jdk11 $module:sonarqube \
-x test \
-x compileJava \
-x compileTestJava \
-x testDebugUnitTest \
-x testDevelopmentDebugUnitTest \
@mickaelcaro You could also add for TravisCI if you like, what we wound up doing is adding an extra “script” call after our main mvn build (or gradle) that updates the normal Java 8 version used for our project builds to JDK 11 temporarily (because the Travis Sonar Scan happens at the end after the build process). Our TravisCI script then looks like this:
Technically the JDK switch script from sormuras “should” be built into the images TravisCI uses, but they must have accidentally removed it at some point. The script is still handy to use with wget.