Re: Move to Java 11 (Java 8 deprecated)

Hi SonarSource community:
Just saw this notice on the SonarCloud documentation pages:

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 , 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?


Hello @Rick-at-KUBRA,

You can find the reason for this move here: SonarCloud scanner environment soon to require Java 11+.

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.

Hope that clears some things up,


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,

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.



Hi @bugbouncer

This requirement will be needed for SonarCloud, no matter where you build your code.

For SonarQube, it will be also the case, but there’s no ETA yet.

@aalmiray are you building Java code with Gradle ? Or another language ?


1 Like

I’m building Java and Groovy code with Gradle.

Thanks. And do you have any concerns moving to Java 11 for the build only (And SC analysis of course) ?

I maintain a Gradle plugin that works as a facade over the Sonarqube plugin
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+.



I created a ticket for that :

We’ll see what we can do.

1 Like

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.

1 Like

Hi @aalmiray

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.

You can find it here :


Hi Mickaël,

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.


1 Like

Joining the discussion on JDK 11 here.

I’m scanning a multi-module Android app that is not ready to be built with JDK 11. It currently builds and runs sonarqube using JDK 8 and Gradle.

Since I’m using the Java plugin there is a built-in dependency on “test” task for sonarqube task.

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 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$jdk11 $module:sonarqube \
-x test \
-x compileJava \
-x compileTestJava \
-x testDebugUnitTest \
-x testDevelopmentDebugUnitTest \

See also the issue: Analyzing Java8 code with JDK11 - deprecations which we face when we tried migration to JDK11 for analyzing

Gradle needs to be upgraded to 5.0 to support java11. We are using lombok as an annotation processor for all our projects and older versions of lombok is broken for java11. If lombok is upgraded to newer version then lot of code files need to be changed.
lombok changelog :
gradle support:

@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:

  - openjdk8
  - mvn clean verify org.jacoco:jacoco-maven-plugin:prepare-agent package org.jacoco:jacoco-maven-plugin:report -B
  # setup JDK 11 for sonar scan
  - wget && . ./ -F 11 -L GPL
    organization: myorg
  - sonar-scanner

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.

1 Like

Thank you very much @Rick-at-KUBRA !

Do we have an exact date for java8 deprecation?