Our project currently uses ./gradlew build sonarqube to build and run Sonar’s analysis, but it’s complaining that our Java 11 image will be deprecated soon and that the temporary fix will end January 28th. Is there any chance that the temporary fix of setting ‘sonar.scanner.force-deprecated-java-version’ to ‘true’ could be extended? Using a Java 17 image in our pipeline causes us to have to update versions of tools used in our code as well, which causes a lot of updates in documentation. Any help in updating our pipeline with minimal updates in our code would be appreciated as well. Thanks in advance!
Hello @elias-aneuvo ,
Welcome to the community!
You can find more information on how to run the analysis with Java 17 and your build with any other version here: Scanner environment & SonarCloud .
2 Likes
Thanks Martin! This is helpful, however, it still requires us to update our code (either due to unrecognized JVM args or outdated Kotlin and Gradle versions) in order to successfully run the Sonarqube analysis. Do you have any suggestions for this?
Hello,
You need to split the build phase that should still run with Java11 from the sonar phase that should run within a Java17 context.
Can you describe what you did to try to run with Java17 and the error message you are getting?
Thanks
Alex
Sure, I’ll be more specific! The pipeline we currently use in Bitbucket runs the command ./gradlew build sonarqube using image: mreichelt/android:latest, which currently only supports up to Java 11. Running our pipeline with this configuration gives us the following error that started this thread:
The version of Java (11.0.15) used to run this analysis is deprecated, and SonarCloud no longer supports it. Please upgrade to Java 17 or later.
Approach
Updating the image to mingc/android-build-box:1.25.0 provides the necessary tools for our pipeline, including Java 17. When running the pipeline using this new image, we get errors stating that our Gradle and Kotlin versions do not support Java 17, so we’re forced to update those (which is not ideal in the current state of our project).
We’ve tried splitting the build so that we run ./gradlew build using the Java 11 image and then ./gradlew sonarqube using the Java 17 image. This, however, produces the same result.
The Gradle/Kotlin version error message:
> Task :app:kaptGenerateStubsDebugKotlin
e: java.lang.IllegalAccessError: class org.jetbrains.kotlin.kapt3.base.KaptContext (in unnamed module @0x1c407bee) cannot access class com.sun.tools.javac.util.Context (in module jdk.compiler) because module jdk.compiler does not export com.sun.tools.javac.util to unnamed module @0x1c407bee
at org.jetbrains.kotlin.kapt3.base.KaptContext.<init>(KaptContext.kt:29)
at org.jetbrains.kotlin.kapt3.KaptContextForStubGeneration.<init>(KaptContextForStubGeneration.kt:40)
at org.jetbrains.kotlin.kapt3.AbstractKapt3Extension.contextForStubGeneration(Kapt3Extension.kt:287)
at org.jetbrains.kotlin.kapt3.AbstractKapt3Extension.analysisCompleted(Kapt3Extension.kt:171)
at org.jetbrains.kotlin.kapt3.ClasspathBasedKapt3Extension.analysisCompleted(Kapt3Extension.kt:102)
at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration$invokeExtensionsOnAnalysisComplete(TopDownAnalyzerFacadeForJVM.kt:112)
at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration(TopDownAnalyzerFacadeForJVM.kt:122)
at org.jetbrains.kotlin.cli.jvm.compiler.TopDownAnalyzerFacadeForJVM.analyzeFilesWithJavaIntegration$default(TopDownAnalyzerFacadeForJVM.kt:86)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:540)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler$analyze$1.invoke(KotlinToJVMBytecodeCompiler.kt:531)
at org.jetbrains.kotlin.cli.common.messages.AnalyzerWithCompilerReport.analyzeAndReport(AnalyzerWithCompilerReport.kt:113)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.analyze(KotlinToJVMBytecodeCompiler.kt:531)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli(KotlinToJVMBytecodeCompiler.kt:188)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinToJVMBytecodeCompiler.compileModules$cli$default(KotlinToJVMBytecodeCompiler.kt:154)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:169)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:52)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:90)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:44)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:98)
at org.jetbrains.kotlin.incremental.IncrementalJvmCompilerRunner.runCompiler(IncrementalJvmCompilerRunner.kt:386)
at org.jetbrains.kotlin.incremental.IncrementalJvmCompilerRunner.runCompiler(IncrementalJvmCompilerRunner.kt:110)
at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compileIncrementally(IncrementalCompilerRunner.kt:303)
at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compileImpl$rebuild(IncrementalCompilerRunner.kt:99)
at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compileImpl(IncrementalCompilerRunner.kt:124)
at org.jetbrains.kotlin.incremental.IncrementalCompilerRunner.compile(IncrementalCompilerRunner.kt:74)
at org.jetbrains.kotlin.daemon.CompileServiceImplBase.execIncrementalCompiler(CompileServiceImpl.kt:607)
at org.jetbrains.kotlin.daemon.CompileServiceImplBase.access$execIncrementalCompiler(CompileServiceImpl.kt:96)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1659)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Request
There was a temporary fix available until January 28th, where we could use the sonar.scanner.force-deprecated-java-version option in our gradle, so I was wondering if there could be an extension for using this option while we (and I’m sure other project owners) are updating projects and dependencies. Or if there is another fix that you’re familiar with, that would be helpful as well!
Thanks in advance!
Elias
Hello,
By default, the Scanner for Gradle always tries to compile even if you don’t specify it.
Here you have to split the activities, so when you are running the sonarqube command do this:
./gradlew -Dsonar.gradle.skipCompile=true sonarqube
By doing this, the Scanner for Gradle won’t try to compile with Java11 and just use Java17 to run the scan.
Alex
Hi Alex,
Thanks for the response! I just tried this and unfortunately, we still run into the same issue. Here’s the most recent attempt for our pipeline if it helps.
dev/*:
- step:
name: Compiling Debug Build
caches:
- gradle
- gradlewrapper
- androidavd
size: 2x # Double resources available for this step.
script:
- curl -sL https://deb.nodesource.com/setup_16.x | bash -
- apt-get install -y nodejs
- bash ./gradlew build
- unset ANDROID_NDK_HOME
- bash ./gradlew assembleDebug --stacktrace -Pdisable-performance-plugin
- . ./setup_export.sh
- curl -X POST --user "${BB_AUTH_STRING}" "https://api.bitbucket.org/2.0/repositories/${BITBUCKET_REPO_OWNER}/${BITBUCKET_REPO_SLUG}/downloads" --form files=@"${LATEST_DEBUG_APK}"
- mkdir -p appOutput
- cp ${LATEST_DEBUG_APK} appOutput
- ls appOutput
artifacts:
- appOutput/*.apk
- step:
name: Running SonarQube Analysis
image: mingc/android-build-box:1.25.0
caches:
- gradle
- gradlewrapper
- androidavd
size: 2x # Double resources available for this step.
script:
- bash ./gradlew -Dsonar.gradle.skipCompile=true sonarqube
Thanks,
Elias
Hey @elias-aneuvo,
To understand why skipCompile doesn’t work I need full logs. And also, the workaround will be to manually exclude failing compile tasks like ./gradlew sonar -x :app:kaptGenerateStubsDebugKotlin (and all other failing tasks).
Best,
Margarita
1 Like
Hi Margarita,
Thank you for your respose! Here’s the log that we receive from our pipeline when running: bash ./gradlew -Dsonar.gradle.skipCompile=true sonarqube --stacktrace --info
pipelineLog-{2f80f33a-4e0d-4f62-9ea4-1f38391d0e0c}.txt (986.1 KB)
Thanks,
Elias
Thanks for your message and sorry for the late reply. Could you please clarify which version of Gradle plugin for sonar you’re using?
Best,
Margarita
Hi Margarita,
Thank you for your response! The SonarQube Gradle version we are using is 3.3. And if it helps, we are using Android Gradle Plugin version 7.0.4 and Gradle distribution version 7.0.2.
Best,
Elias
Hey @elias-aneuvo,
Thanks for your reply. This option skipCompile is available starting 4.4 if I’m not mistaken. Could you, please, upgrade to the latest Gradle plugin and run it again?
Best,
Margarita
Hi Margarita,
Thanks for your response! Can you provide an example for how we can build using Java 11 and then run sonarqube using the skipCompile option using Java 17 please?
All the best,
Elias
Hey @elias-aneuvo
The docs here should help:
# Gradle
gradle build ...
export JAVA_HOME=/path/to/java17
gradle -Dsonar.gradle.skipCompile=true sonar
Hey Colin,
Thanks for your response! I believe this should work locally, however, if I were to include this in our pipeline, would I just replace export JAVA_HOME=/path/to/java17 with the image, which includes the Java version, we want to use?
All the best,
Elias
I’m not sure what you mean by “replace with the image” but in any case, as long as the build artifacts are available and Java 17 is configured as JAVA_HOME, you should be good to go.
Hey Colin,
Sorry for being unclear. This is our original pipeline that we were running into issues with for context:
image: mreichelt/android:latest
...
- step:
name: Compiling Debug Build
caches:
- gradle
- gradlewrapper
- androidavd
size: 2x # Double resources available for this step.
script:
- curl -sL https://deb.nodesource.com/setup_16.x | bash -
- apt-get install -y nodejs
- bash ./gradlew build sonarqube # For Sonar Cloud
- unset ANDROID_NDK_HOME
- bash ./gradlew assembleDebug --stacktrace -Pdisable-performance-plugin
- . ./setup_export.sh
- curl -X POST --user "${BB_AUTH_STRING}" "https://api.bitbucket.org/2.0/repositories/${BITBUCKET_REPO_OWNER}/${BITBUCKET_REPO_SLUG}/downloads" --form files=@"${LATEST_DEBUG_APK}"
- mkdir -p appOutput
- cp ${LATEST_DEBUG_APK} appOutput
- ls appOutput
artifacts:
- appOutput/*.apk
The Android docker image that we pull in the first line comes with Java 11. So taking your previous response into consideration, our pipeline should still use that image to build with ./gradlew build. Then we should pull a separate Android docker image with Java 17 before running ./gradlew -Dsonar.gradle.skipCompile=true sonarqube. This is our current pipeline, assuming that approach is correct.
...
- step:
name: Compiling Debug Build
image: mreichelt/android:latest # image with Java 11
caches:
- gradle
- gradlewrapper
- androidavd
size: 2x # Double resources available for this step.
script:
- curl -sL https://deb.nodesource.com/setup_16.x | bash -
- apt-get install -y nodejs
- bash ./gradlew build
- unset ANDROID_NDK_HOME
- bash ./gradlew assembleDebug --stacktrace -Pdisable-performance-plugin
- . ./setup_export.sh
- curl -X POST --user "${BB_AUTH_STRING}" "https://api.bitbucket.org/2.0/repositories/${BITBUCKET_REPO_OWNER}/${BITBUCKET_REPO_SLUG}/downloads" --form files=@"${LATEST_DEBUG_APK}"
- mkdir -p appOutput
- cp ${LATEST_DEBUG_APK} appOutput
- ls appOutput
artifacts:
- appOutput/*.apk
- step:
name: Running SonarQube Analysis
image: mingc/android-build-box:1.25.0 # image with Java 17
caches:
- gradle
- gradlewrapper
- androidavd
size: 2x # Double resources available for this step.
script:
- echo "Changing org.gradle.jvmargs in gradle.properties for Java 17 analysis"
- sed -i 's/org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8/org.gradle.jvmargs=-Xmx2048m -XX:MaxMetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8/' gradle.properties
- cat gradle.properties # Verify change
- bash ./gradlew -Dsonar.gradle.skipCompile=true sonarqube
This, however, still gives us this compile error in the pipeline:
Could not compile settings file '/opt/atlassian/pipelines/agent/build/settings.gradle'.
> startup failed:
General error during conversion: Unsupported class file major version 61
java.lang.IllegalArgumentException: Unsupported class file major version 61
This leads us to assume that we aren’t able to run the analysis with our project because it doesn’t support Java 17.
These are some of our dependency versions for more context:
- Sonarqube 4.4.1.3373
- Gradle 7.0.2
- Android Gradle Plugin 7.0.4
- Kotlin 1.5.20
- Java 1.8 (aka Java 8)
Our main goal is to still be able to use the Sonarqube analysis in our pipeline without having to update any of our Gradle/Kotlin/Java versions since we do not have the bandwidth to do so just yet. I hope this helps provide more info and please let me know if you need more information to help us accomplish this!
All the best,
Elias
Thanks. I think you’re running into [SONARGRADL-134] - Jira.
Meaning that for now, you can set it as a system property in settings.gradle.
Hi Colin and all,
Thank you for your help! This latest solution still did not work for us, but we recently had bandwidth to update our app’s dependencies. We now support Java 17 and the original sonarqube gradle analysis works now.
All the best,
Elias
2 Likes
What are the risks with using Java 11 on my Jenkins controller scanning jobs through SonarQube platform running version 10.21? My current timeline to upgrade my Jenkins controllers to using JDK 17 installed and meet the new SonarQube requirements for JDK 17 is June 2024.