Android's list of hard rules for writing Java for Kotlin consumption are here: https://android.github.io/kotlin-guides/interop.html#java-for-kotlin-consumption

I'm gonna say generous use of the Nullability Annotations. This will allow Kotlin to better infer what is being used, and translate to nullable or not types.

We leaned pretty heavily on lombok, but that caused us some headaches when trying to incrementally convert to Kotlin. You can't reference generated lombok classes from kotlin easily, and if you do it breaks referencing kotlin from java (at least that was the state last I looked). When we tried to move to kapt, lombok decided to stop playing nice, so had to remove it (lombok) in one big sweep.

Yuck, just going through this. The official response is kotlin can call lombok'ed java if it lives in a separate module. Which is fine if you want to include a legacy source module, but can't be used in a progressive refactoring mode since you eventually end up between circular dependencies between java and kotlin modules.

Just in case somebody else is also in pain, Android Studio 3 beta6 was the last version before the kapt3 upgrade breaking lombok annotations in the same module.

Kotlin's standard library has lots of great extension and utility functions for dealing with strings, files, etc. You can of course call the extension functions from Java, although the syntax isn't as nice.

So you may find you no longer need Guava. If you were considering using Guava in your project, you may now be able to avoid it, and drastically slash your dex method count.