If a service is mature and we don't expect to do any further changes, I'd leave it be. I'd look at it on a service by service basis. It's almost a Java 2.0.ĭo you think the migration effort would be worth it? In my experience, good Java devs are productive in Kotlin within a week or so. The project has a lot of code and design issues itself, developers (4 total) don't have a lot of experience with Kotlin, some none at all. So why not? You're not really giving arguments. It was decided that current code should migrate to Kotlin over time, I am trying to get an opinion on this, but from what I learned so far I think it's not worth the effort to go through migration of this scale.

If kotlin provides enough benefit that your technical stake holders agree it’s the way to go over Java, doing the migration incrementally will dramatically improve odds of a successful transition because you won’t be holding up delivery of business value for benefits that aren’t visible to the end users of your software. Start by adding kotlin alongside Java, tackle small hanging fruit (when I did a similar effort, there was a lot of removed code by simply converting large POJOs to Kotlin data classes) and then incrementally convert Java stuff to kotlin as it makes sense and leave the Java where there isn’t a clear benefit to rewriting it.Ĭommitting to a rewrite of existing, valuable software regardless of language is a long, error prone, and expensive commitment that requires careful thought and planning to execute properly as well as total buy-in from technical and business stakeholders. There’s a reason that JetBrains put so much effort in to making the kotlin/Java interoperability so awesome.

Java to kotlin converter