Did a recent update in a project from Kotlin `1.8....

# getting-started

[Pablichjenkov]

Did a recent update in a project from Kotlin 1.8.22 to 1.9.25 and I am noticing some changes I haven’t heard of. I have the following Java definition:

public abstract class Abc<T> {
  void function1(@NonNull T t)
}

In Kotlin 1.8.22, below code compiles without issues.

class AbcSubclass1<T> : Abc<T> {
  override fun function1(T t) = Unit
}

But in Kotlin 1.9.25, I get a type mismatch error. Then the compiler/IDE suggest the following code which compiles perfectly:

class AbcSubclass2<T> : Abc<T> {
  override fun function1(T & Any t) = Unit
}

Notice the type T vs T & Any, it seems like a new language enhancement to typing.
Am I right?
Is this the best fix or Perhaps defining the class like below is better?

class AbcSubclass2<T : Any> : Abc<T> ...

[Szymon Jeziorski]

What you're seeing is related to definitely non-nullable types (docs).
From what I can see here they were promoted to stable in 1.7 so I'm surprised you're only getting the error now, but maybe some behavioral changes or fixed were made to it between 1.8.22 and 1.9.25

And to answer question, in your case I would opt for using generic upper bound class AbcSubclass2<T : Any> : Abc<T> as you said.
I would only go for per-method T & Any in case when Java class you're inheriting/implementing contained both methods that could work with nullable T and the ones that expect not-nullable T

[Pablichjenkov]

Interesting right, 1.8.x never complained about this. I never used 1.7.x, I jumped from 1.6 to 1.8 but still, seems like something new was added. I think it is worth clarifying such a java class above is in an .jar, the file is not in code but is compiled into a jar that other libraries consume.

[Youssef Shoaib [MOD]]

That really shouldn't be an error though. It's fine for you to take a superclass of a parameter. For instance, if you took in Any, that'd be allowed. I think this should thus compile. Maybe file a bug on youtrack?

[Pablichjenkov]

Ah ok, Let me check once more. I want to make sure we don't set specific compiler flags in our convention plugin

[Pablichjenkov]

I side with you on this one should not be an error. Although right now, I am thinking perhaps the error comes from dagger kapt

[Youssef Shoaib [MOD]]

Nvm I'm dumb and forgot how override works in Kotlin lol. So yeah you have to match the signature in every way except the return type, which can be a subtype. Hence this error is actually consistent
I.e this compiles:

abstract class Base<T> {
    abstract fun foo(): Any
}

class Bar<T>: Base<T>() {
    override fun foo(): String = "hi"
}

but this doesn't:

abstract class Base<T> {
    abstract fun foo(x: String)
}

class Bar<T>: Base<T>() {
    override fun foo(x: Any) {}
}

and similarly, your case shouldn't compile either. A better error message would be nice potentially though

[Pablichjenkov]

Right once you read the docs link above by SJ, it explicitly cites that use case.
Now why it didn't cry before with 1.8.22, no idea. But it makes sense and feels more null-able type safe now.