I am working in a JVM only setting. There are a lo...

# getting-started

[dirk.dittert]

I am working in a JVM only setting. There are a lot of interfaces in Kotlin that also exist in Java (e.g. IllegalArgumentException or Comparable). Are there any best practices on how to deal with that? For example, if there are any Java consumers, they would not expect a class to implement kotlin.Comparable but the Java equivalent. Is there a way to easily flag these cases with code analysis? Are there any downsides from a Kotlin perspective to not use native functionality?

[Sam]

In those cases and most similar situations, the Kotlin type will act as an alias for the Java one, so you should be fine with either. I have a slight preference to stick to the Kotlin ones, even when I know the JVM will be the only target, since they can be a little more expressive when it comes to generics and nullability.

[dirk.dittert]

Thanks for the explanation. On closer examination, I see the that it is public actual interface Comparable in Kotlin. Is there a corresponding expect declaration somewhere and how can I navigate there?

[dirk.dittert]

I can see for the IllegalArgumentException that it just is a type alias.

[Sam]

Some classes like Comparable and List are just magically translated by the compiler when targeting Java. I think it's mostly done that way because they were added to the stdlib before expect/actual was part of the language, but I may be wrong. I'll see if I can find some documentation about it.

[Sam]

Looks like there's a list here: https://kotlinlang.org/docs/java-interop.html#mapped-types

[dirk.dittert]

Thanks.

[ephemient]

in some cases there are even classes that are mapped multiple times, e.g.

typealias kotlin.coroutines.cancellation.CancellationException = java.util.concurrent.CancellationException
typealias kotlinx.coroutines.CancellationException = java.util.concurrent.CancellationException

[ephemient]

and while those are the "same" type, there are also kotlin.collections.Collection = java.util.Collection = kotlin.collections.MutableCollection (ditto for List and Set and Map) which are different types in Kotlin that map to the same platform type in Java

[dirk.dittert]

Yes, I have already noticed that Kotlin has a better approach to collections. Let's call them "intended to be mutated" and "not intended to be mutated"