Using K1 for sonarqube analysis on Kotlin

SonarQube Server / Community Build
,
1

Hi there,

We’re using sonar server v2025.2 (105476). I see that sonar analyzer uses K2 for analzying the kotlin code Sonar's Kotlin analysis is now based on K2 and supports Kotlin 2.1.

However this can lead to some issues when we’re compiling the code with K1.
For example;

with K1 enabled


class Foo(val name: String?)
data class Bar(val foo: Foo?)

fun testBar(bar: Bar?) {
    if (!bar?.foo?.name.isNullOrEmpty() && bar.foo != null) {
        println("all good")
    }
}

will not compile with the error at bar.foo since we are doing an unsafe check for bar.foo.

This would however compile with K2 since the compiler can infer the non null nature of bar .

As such is there a way of reverting the sonar scanner to use K1 instead of K2 depending on the codebase.

Thanks

4

Hello @sonardroid,

Thanks for your report.

First of all, I’m curious to know any reason for using K1 and not K2. The migration is supposed to be pretty smooth, so let us and probably Kotlin team know if you have problems during the migration)

We don’t plan to allow users decide whether to use K1 or K2 modes for Analysis API as this means 2 separate setups, 2 sets of dependencies and drastically increased plugin size. However we knew that not all the users might have migrated to Kotlin 2.0+, so we tested K2 mode with different language versions (1.6..2.1) and it seems to understand the semantic constraints correctly.

So, could you please set your language version for the Sonar analyzer (see docs) to something lower than 2.0 (for example, 1.9) and check if you still see incorrect resolution.

sonar.kotlin.source.version=1.9

Best,
Margarita

5

Hi @Margarita_Nedzelska ,

We use sonar.kotlin.source.version=1.9 and see this issue being reported. If we were to use the new compiler , then this issue would be resolved. However it comes up because compile with K1. As such while the semantic constraints are correct for K2, it is not correct for K1.
We are using Kotlin 1.9.21 which means if we were to switch our kotlin setup to use K2 this would compile correctly. But since K2 shipped with Kotlin 1.9 is in Beta, there are some issues which prevents us from using it.

I realise that I missed updating why this is an issue for us. Adding those details below;

Since we compile with Kotlin 1.9.21 with K1 enabled;
We would need to have the following functional definition

fun testBar(bar: Bar?) {
    if (!bar?.foo?.name.isNullOrEmpty() && bar?.foo != null) {
        println("all good")
    }
}

However sonar then highglights a codesmell where the bar?.foo has an unnecessary null check which is a a valid codesmell while using K2.

However since we use K1 , we need this null check to be present.

6

Thanks for clarifying.

You don’t have to enable K2 for 1.9 in beta. What I was interested is more, is there any blocker for you to migrate to 2.0+ where K2 is default.

Now that I looked closer at your example, looks like your second condition is unnecessary as it’s always true and regardless of the mode(K1 or K2) IntelliJ reports this. However, I was able to reproduce your issue. Looks like that regardless of the language version, the Api we’re using in this rule implementation to detect nullability returns non-nullable type in your case, while compiler of 1.9 is not able to smart-cast it. I am not completely sure if the issue is the fact that such check is unnecessary or just wrong type resolution.

I will need to have another look to understand if we can get the compile-time nullability differently or this is a compiler api bug and the type must be nullable here. Will keep tack of the issue on our side and see if more users report this. Meanwhile, feel free to close such issues on your side as FPs (I hope they’re not a lot).

And I still hope you’ll manage to migrate to Kotlin 2.x to benefit from the improved type resolution and lots of other great features.

Best,
Margarita

7

Hi there,

In my tests, when I use K1 mode in intellij ,this null check is necessary.Does intellij show this as unnecessary for you with K1 enabled? The Kotlin 2.x migration is on our immediate roadmap :slight_smile:

Thanks for providing the details for the issue. We’ll go ahead with this closing this as an FP for now. We’ve come across one such issue right now. I also hope there aren’t too many :crossed_fingers: