Instead, having a completely rewritten codebase is an end goal you work towards in small increments. With this strategy you avoid having to spend a lot of time upfront to rewrite your whole codebase. In this case you write all new features in Kotlin and additionally rewrite all existing Java code touched by this new feature, but not any other existing Java code. However, it probably is not worth it, if the code is hardly ever touched.Īnother approach is to take smaller steps. It may be worth it, if the code you rewrite is in constant development. Since this strategy can be really time consuming, depending on the size of your codebase, ask yourself if it’s worth the time. This will only get you partly there though, the generated Kotlin code is often still very Java-ish and needs some refactoring to become clean and idiomatic Kotlin code. IntelliJ has a feature to do this for you automatically via Code → Convert Java File to Kotlin File. If your codebase is small, you might consider to rewrite all existing Java code to Kotlin.

But that is just one suggestion, it might be good to consider what suits your needs the best.

In the introduction, the first migration strategy was already mentioned: keep existing code in Java and only write new code in Kotlin.

Kotlin and java