I haven't used Kotlin on Android, but on the server side, it does make some of the boring stuff easier if you're stuck on an old JDK - e.g., Jackson supports serialising/deserialising straight into Kotlin data classes, you don't need this if you can use Java 14+'s records, but if you're still on Java 8, it's far nicer than all the boilerplate POJOs.

As for the DB layer, I quite like JDBI which integrates well with Kotlin also: https://jdbi.org/#_kotlin

I'm not familiar with RxAndroidBLE, but they have some Kotlin examples on GH: https://github.com/Polidea/RxAndroidBle/blob/master/sample-k...

I'm (slowly) in the process of migrating an Android app from Java -> Kotlin. The compatibility with Java is pretty amazing. Mixing the two languages feels almost the same as two java files.

There is a bit of cognitive overhead at first, but that's the overhead of learning a new language. Plus I immediately see the benefits, specifically WRT optionals (?. and ?: operator).

On Android, it is kind of clear, Google is doubling down on Kotlin and the team is hardly motivated to move Android Java into proper Java, so long term Kotlin seems to be the only path forward.

Still cherry picking features from Java 11 when Java 17 just got released, https://android-review.googlesource.com/q/project:platform%2...

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.

Not personally but it's happening in a few apps at my current company. In my job I mix Java and Groovy and at home I've mixed Java and Kotlin and it mostly just works (I don't think you can inherit Java -> other language -> Java because things get compiled in order but that has only been an issue for me once).

You can do Java -> Kotlin just fine.