Since the latest announcement at Google I/O, things have been crazy. At the Kotlin Weekly Mail List, we had an increase in subscribers over 20% in the last two weeks, over 200% increase in article submissions, and at a Meetup I organize (Kotlin Users Group Munich), we had a huge increase in attendees. And all this combined with the general blast in the developers' community.

A trend that will only continue to grow.

It is somehow obvious now where the future is leading. Although Google promised to keep support for Java, the legal battle between Google and Oracle and the clear fact that Kotlin is a more succinct, effective, and powerful language is marking the direction in a sea of reeds. I found this tweet to be fairly predictive:

A few months ago, when I was present in a Kotlin-related environment, probably the most recurrent question was whether it was a good time to start a migration into Kotlin. My answer was always invariably YES. There were many benefits and almost no drawbacks if you proceed with a Kotlin migration. The only technical drawback I could think of was increasing the method count number, since kotlin-stdlib adds (currently) 7191 new methods. Considering the new benefits on the table, that was a more than acceptable disadvantage.

Now that the answer to that question is affirmative without any kind of palliatives, I realized there is another question floating around: what is the process to start adopting Kotlin?

In this article, I am aiming to provide a few ideas for those of you confused about where to start or looking for new ideas.

1. Start With the Tests

Yes, I am aware that tests are limited in nature. A unit test means exactly that: you are testing individual units and modules. It is hard to develop complex architectural nets when all you have is a bunch of single classes and maybe a few helper ones, but this is a very cheap and effective way to build awareness and spread knowledge of the new language.

One recurrent argument I have heard against Kotlin is to avoid deploying into production code lines written in Kotlin. As much as I think this is a highly-coloured problem, I want to emphasize this to you. If you start with the tests, no code is being actually deployed. Instead, this code is being used likely in your CI environment and as a way to extend knowledge.

Start writing new tests in Kotlin; they can cooperate and talk directly to other Java classes. When you have some idle time, migrate the Java classes, check the resulting code and apply whatever transformation you find required. In my personal experience, 60% of the transformed code is directly usable, and a bigger percentage for simple classes with no complex functionality. I find this first step as a very safe scenario to start with.

2. Migrate Existing Code

When you first start dealing with your productive code, I have found it effective to start first with the classes of less impact: DTOs and models. These classes have an extremely low impact, and they can be easily refactored in an exceptionally short time span. It's the perfect time to get to know data classes and seriously reduce the size of your codebase.

After this, start to migrate unitary classes. Maybe the LanguageHelper, or the Utils class. Although widely used, this kind of class tends to provide a set of functionality limited in relationships and impact.

At some point, you will feel comfortable enough to tackle the bigger and central classes of your architecture. Do not be scared. Pay special attention to the nullability- this is one of the most important features of Kotlin. It will require a new mindset if you have been programming in Java for a few years, but the new paradigm essentially will set in your mind, believe me.

Remember: you do not need to stress about migrating the entire codebase. Kotlin and Java can seamlessly interact, and there is no need now to have a 100% Kotlin code. Do it until it feels comfortable.

3. Go Wild With Kotlin

At this point, you can definitely start writing all the new code in Kotlin. Think of this as a previous relationship, and do not look back. On top of the mentioned nullability, when you are starting to write your first features in pure Kotlin, pay attention as well to the defaulted parameters. Think in terms of extension functions rather than inheritance. Do pull requests and code reviews, and talk with your colleagues how things can be done better and improved.

And the ultimate tip: enjoy!

Resources to Learn Kotlin

The following is a list with links I have tried and can recommend to learn Kotlin. I am particularly fond of books, although some people dislike them. I find it pretty important to read them aloud, writing over them and practicing on the computer at the same time to sediment knowledge better.

I write my thoughts about software engineering and life in general in my Twitter account. If you liked this article or it helped you, feel free to share it, ♥ it, and/or leave a comment. This is the currency that fuels amateur writers.