I agree. Two years ago a slide at a Google I/O talk said "Coroutines first", and coroutine scopes like lifecycleScope are Kotlin only.

Jetpack Compose is the future of Android UI and is Kotlin only.

Insofar as bringing it into the app - from most apps I know of, new code is usually written in Kotlin, and the Java code becomes legacy (which is sometimes rewritten in Kotlin). It works well enough, compatibility with existing Java was important to the Kotlin team (for adoption and other reasons).

Read the Kotlin docs for more https://kotlinlang.org/docs/jvm-get-started.html . You definitely see some of the things mentioned when using both languages, like the JvmStatic annotation etc.

The problem with that strategy is that as the JVM gets Loom, SIMD, JNI replaced by Panama, bytecodes that don't translate to DEX,... the amount of Java libraries available to Android developers diminishes.

So doing Kotlin in Android, with an anti-Java agenda, reduces Kotlin to use pure Android libraries, or pre-history Java ones that can still be called from Android Java.

Oh really? Is this still a hangover from the Oracle lawsuit stuff?

I might give it a whirl and start replacing the easy stuff first. In my system the worst part is the Android app and anything that makes it easier to maintain in the long term is welcome.

edit: Not sure how I missed this announcement: https://www.zdnet.com/article/google-were-using-kotlin-progr...

Oracle has nothing to do with it, given that Kotlin and Android Studio are fully dependent on the JVM ecosystem.

If that was the reason Dart would have been a better option, but I bet the Android team is not that keen on having Fuchsia take away their party, hence JetPack Composer.

Google can say they get less bugs, and that's probably true, but I'm sure it was partly a strategic hedge in case they lost the lawsuit with Oracle as well.