How to Convert a Project From Java to Kotlin Without Pain and Why It Is Necessary

In one project, we got an application that contained half of the source code in Java, and the other half in Kotlin. In fact, I asked a question: "Why is it so?" The conclusion was simple.

Developers could not cope with the problems that this transition had brought. We were faced with the task of putting things in order and dealing with this problem.

First of all, we need to begin with why I think this transition may be necessary.

Hype

This is, of course, a joke with a grain of truth. However, a huge number of developers can be enticed in this way. Kotlin allows you to look at the routine Spring Rest application from a new angle, bringing a functional programming style. As well as giving such features as:

• Raw types - getting rid of ClassCastException when a variable storing an object parametrized by another type gets into the heap.

• Nullable safety - Kotlin's programming style allows you to protect yourself from NullPointerException by simply not allowing their use (in fact, it does, but the problem is related to this further on).

• A high-order function is what I wrote about above - the transition to the functional programming style, when the function takes as a parameter other functions.

• Data classes, which will save you from using Lombok.

• etc.

And Now to the Problems

Forget about the auto-convert IDEA from Java to Kotlin. The first thing you will find is completely crookedly written Java-style code that is converted. For example, you can take a PNG and convert it to JPEG.

Yes, the result will be the same, except that the original properties (transparency) will be lost. It's the same here. You will get the working code, however, I don't think you'll be thrilled to maintain it. Get used to the idea that YOU HAVE TO REWITE IT.

Put on Lint, and read some books on approaches and styles. See it through to the end. The only place where I can recommend you to use this method is Data-classes. Also, all new functionality must be written exclusively in Kotlin to avoid a repeat of the story with the problems.

Do Not Abuse Nullable Safety

There will be a wild desire to start using this very useful thing, however, if you keep in mind your API users, they definitely won't be thrilled that you're ruining their interaction with you.

So the API versioning + thinking "Do I really need this very Nullable safety in my future logic?" would come in handy here.

You can always protect yourself at controller level with the required Spring and Lombok. You're bound to run into the fact that by default, Kotlin classes are closed to inheritance, so if you don't "open" classes with annotations like @Configuration and @Service, it will lead to startup errors.

And Lombok will throw you a few surprises because annotations break the logic of converting classes to Kotlin

What's the Conclusion?

Stop using the technology zoo. Often, it doesn't lead to anything good. If you dare - see it through to the end, so that you and your work are not left with unpleasant impressions