12 steps to convert your Java class to Kotlin the right way
Sure, it’s easy to have Android Studio convert your Kotlin class for you, but the results are rather messy! Like any automated tool, Android Studio does its best for an automatic conversion, but it leaves a bit for developers to clean up. Your class probably won’t compile, you’ve got null exceptions everywhere, and even after you’ve cleaned it up, how do you even tell if your class still works like it should?! Read on!
Here are 12 steps to take that solve the automated Kotlin conversion mess.
Step 1: Black Box unit test before you convert
How do you make sure you don’t break a class with the Kotlin conversion? You unit test it before you make the change. Yay Test Driven Development!
You probably won’t get any gain by testing nulls because Kotlin changes nullability, but it’s a good idea to black box test the class for its main features / happy path at least. Once you’ve gotten your tests to pass, you know that if they pass for the Kotlin version, your class still has the functionality it did before.
Step 2: Git Shenanigans for cleaner PRs
Does your team do code reviews? Do this step to help your reviewers understand what changed in your code! If you just change the Java file to Kotlin, git will see that as you deleting the whole Java file, and creating a new Kotlin file. 1) That’s not helpful for figuring out what changed and 2) you will lose all your previous file git history!
Here’s how to fix that issue:
1) Rename your .java file to have a .kt extension. Commit that change.
2) Rename your .kt file back to .java. Commit that change.
3) Now after you’ve made the actual conversions and committed, rebase and squash those commits into your .kt file back to .java commit, and your git will just show the changes you made within the Kotlin file code.
Step 3: Auto Convert with Android Studio
Now, you can use Android Studio to convert your Java class to Kotlin. Just go to Code > Convert Java File To Kotlin. I usually also allow Android Studio to automatically convert any Java references to my file to the appropriate code to deal with Kotlin.
Step 4: Get Rid of the !! Not Null Assertion Operators
When you automatically convert your Java class to Kotlin, Android Studio will stick a bunch of !! operators into your code to handle nullability. This is the Not Null Assertion operator, which will check if the object is null and throw an exception if it is. This is generally not what we want — for example, you wouldn’t want to crash the app on a null view or a null context. Remove the !!’s and use the nullable operator instead (?), or look into your code and see if you needed that value to be nullable.
Step 5: Companion objects and @JvmStatic
Kotlin conversion will move your static objects/methods into Companion objects if you have a regular class, and you might notice that all your Java uses of those objects/methods now have a .Companion reference to them. If you like, you can reference them just as before if you add @JvmStatic to those objects/methods, and this will tell the compiler to generate them as additional static objects/methods.
Step 6: Revisit your APIs
Since you’ve converted your class to Kotlin, you may have noticed that your APIs look a little different. @NonNull arguments now enforce the non-null, and if you didn’t specify non-null, the arguments are marked as nullable. You may want to revisit these APIs to see if they’re meant to be non-null or nullable, and if they’re being used properly across the app. It’s best to bring in your team and communicate changes, especially if your API is being used outside of your code’s scope.
Step 7: Lambdas
One of my favorite parts of the Kotlin language are lambdas. They’re so easy to use and they make developing callbacks, listeners, and functions a cinch! Go through your code, look for click listeners, callbacks, and methods that can be converted to lambdas. Android Studio will often help you out here by highlighting or graying areas that can be fixed to be more performant. You might even consider updating your APIs to use lambdas. (Warning: Using the lambdas in your APIs in Java code may result in some strange looking code. Java 8 does have the concept of lambdas, and Java 7 has functions, but their syntax handling of Kotlin lambdas can be a bit strange).
Step 8: Fixing for loops, inline returns, and using when
Kotlin can replace for loops with a .forEach or a .forEachIndexed:
You can also go through all of your single line return methods and make them inline. Take a look at all your uses of return. Android Studio often has suggestions on how Kotlin can make returns or assignments inline.
One of the most powerful keywords in Kotlin is when. It can replace switch-statements and if-statements and can execute logic to determine the control flow.
Step 9: Document, Document, Document!
Just as with any code change, you should understand the code you are dealing with, and use that time to add method / class comments to your code. Yes, we want to write clean code that is self-explanatory, but having a quick comment about purpose of the code or how its used can be invaluable for debugging, reading, or even re-architecting later. Do your future-self and your team a huge favor — document!
Step 10: Unit test again
Make sure that your code passes your black box unit tests. If not, fix the code. If so, write more unit tests! Unit testing can help you catch edge cases and make sure the code works as you think it should. Bonus: you can up those code coverage numbers while you convert your code to Kotlin.
Step 11: Visual QA (If possible)
Save your QA team a cycle! Before you send your work on to code review, if you’ve updated a UI class, or touched logic that affects that UI, you should run your app and make sure that screen looks right, just in case.
Step 12: Rebase your commits for clean Git Diff
As mentioned in the Git step, you should rebase your commits back into your .kt → .java commit so that you can get a clean git diff for your code reviewers to read. This will help immensely to figure out what actually was changed in the code, rather than having to re-review the whole (potentially huge) file.
DONE!
Congratulations! You’re done converting your Java file to Kotlin! You now have a beautiful new Kotlin class that’s been well-unit-tested and verified. Give yourself a pat on the back and send your work off to be reviewed! You did it!
“The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License.”
