SonarQube sometimes reports deprecation warnings (kotlin:S1874) for List methods that aren’t deprecated.
Kotlin’s List<T>.first() extension method.
Java’s List.removeLast() method.
This happened immediately after I upgraded the project’s JVM toolchain from Java 17 to 21. The methods aren’t deprecated in Java 21.
Weirdly, not all occurrences of these method calls are being reported. F.e. myGenericList.first() got reported, but myString.split('-', limit = 2).first() didn’t. (Where myGenericListhas the type List<T> with T : Any.)
SonarQube: 9.9.2 (not sure about the deployment type)
I can’t reproduce your problem. Neither of both examples triggers S1874 for me. I’m using the same toolchain version as you, except for SonarQube 9.9.3 (but I don’t think that makes the difference). Maybe can you provide me with some more information? (i.e., your build script and a minimal source file in which the problem occurs).
This is my minimal setup in which I couldn’t observe the described effect:
Main.kt:
// Unused import to get at least one report in SQ
import java.awt.ActiveEvent;
fun <T: Any>foo(myGenericList: List<T>): T {
return myGenericList.first()
}
fun bar(myString: String): String {
return myString.split('-', limit = 2).first();
}
build.gradle.kts:
import org.jetbrains.kotlin.gradle.tasks.KotlinCompile
plugins {
kotlin("jvm") version "1.9.21"
id("org.sonarqube") version "4.4.1.3373"
}
group = "org.example"
version = "1.0-SNAPSHOT"
repositories {
mavenCentral()
}
java {
toolchain {
languageVersion = JavaLanguageVersion.of(21)
}
}
tasks.withType<KotlinCompile> {
kotlinOptions.jvmTarget = "21"
}
I’ve directly copied your minimal setup into a fresh, empty project. The issue also appears there. (In foo. bar isn’t affected.) The only other files in the project are gradle.properties with the Sonar URL and project key, settings.gradle.kts with the root project name, and the Gradle Wrapper files.
We’ve also updated SonarQube to version 9.9.3, but that didn’t change anything.
This is strange. Maybe could you provide me also with the gradle.properties and settings.gradle.kts? These and Temurin should now be the only three differences between my and your setup. I’ll try these too and then get back to you.
I’m just asking for completeness to rule out any other causes for this behavior: you are using the Gradle wrapper when doing the analysis, i.e., ./gradlew, not gradle , right?
I’ve tested a bit more. The issue appears when I execute ./gradlew using Java 21, but not when I execute it using Java 17. The configured toolchain doesn’t matter.
I.e. I can change 21 to 17 in build.gradle.kts and the issue still appears. But if I change my shell’s default Java version to 17 (using SDKMAN!'s sdk use java 17.0.9-tem), the issue disappears, even if the Gradle Java toolchain still uses Java 21.
I’ve also tried a different vendor (sdk use java 21.0.1-zulu), but the issue still appears.
Note: the deprecation rule in Kotlin is based on the Compiler warning, so this means that the rule itself should work correctly but there might indeed be misconfiguration.
Let’s wait till the ticket is fixed, and then get back to us if the issue is still there.
This particular rule in our analyzer comes directly from the Kotlin compiler diagnostic.
And the issue with it is reproducible in SonarQube Server version 9.9.3 (where our Kotlin analyzer is based on Kotlin compiler version 1.7.10) exactly as was earlier described by topic starter @GeorgEchterling
And we can see that this issue does not appear after following the same steps with
SonarQube Server Developer Edition v2025.1.3
where our Kotlin analyzer is based on Kotlin compiler version 2.0.21
Unfortunately, your example
fun foo(bars: List<Bar>) {
bars.first().spam
~~~~~~~
Deprecated code should not be used.
}
does not allow us to reproduce it either.
So we consider that original issue reported here was fixed.
@GeorgEchterling could you please also check that the issue is fixed for you after the SonarQube upgrade to at least current LTA version 2025.1 ?
@arek maybe you’re facing something different or under different conditions, but to investigate we need you to provide complete example (eg project in GitHub) that we can use to reproduce the issue - once you can provide it, please create a new thread, providing the example and all the necessary details to reproduce it.
