If you run gradle build -dry-run in your project, you will see what tasks will be performed in which order. If your Java code has classes which heavily rely on Lombok, for example, using the annotation, this becomes tricky when calling this Lombok-generated code in Kotlin.The reason for this has to do with the compile dependency.
Just starting out and seeing where you end up, is probably a bad idea. Whatever strategy you choose, it is at least good to consciously choose one. These are just some suggestions for your migration strategy.
This way it can benefit from all Kotlin has to offer, and you can keep the outside code written in Java. For example, if you use the hexagonal architecture (also known as ‘ports and adapters’), it makes sense you want to have the inner part, your core business logic, rewritten to Kotlin. You can also distinguish what code to keep in Java and what code to rewrite to Kotlin, by looking at its function from an architectural perspective. 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.
0 kommentar(er)
