Learnings from Two Years of Kotlin
In case you missed it, Expedia got a call out in Google’s Developer Keynote at Google I/O yesterday as well as on the Android Developers blog.
Google announced that Kotlin is now ready, mature, and fully supported as a first-class language for Android development, highlighting four major applications (including ours) already heavily invested in the new language.
The Expedia brand Android native app team has been using Kotlin in production for a couple of years, making Expedia one of the earlier adopters of Kotlin for Android development. Recently Kotlin has become all the rage in Android development; community adoption and support in all sorts of applications drove Google to promote it to first-class status.
Here at Expedia we’ve come to love Kotlin and can’t imagine going back to pure Java. We are super excited to see what Google’s first-class treatment brings to Android. In the spirit of sharing our learnings, here are some of the things that we have found along the way:
What we love
There are lots of reasons to love Kotlin, and there are lots of blog posts floating around the web that will happily proselytize to you. Here are some of the specific benefits that we have seen from adopting Kotlin:
- Seamless interoperation with Java allows us to slowly migrate to Kotlin without having to throw away all of our current, working code. After about 2 years our Android app is approaching an even split between Java and Kotlin code, according to our GitHub statistics:
- Converting to Kotlin has been fairly painless, thanks to functionality built into the Kotlin plugin for IntelliJ that automatically converts Java code to Kotlin. It detects code that is copy-pasted from Java to Kotlin, or can mass-convert entire classes.
- The explicit handling of null in Kotlin has helped us to dramatically reduce the number of dreaded NullPointerExceptions encountered by our users in the wild; a big part part of helping us drive our crash rate down to less than 1% of sessions. It’s not perfect; null values can still be injected into Kotlin from Java with a bit of (perhaps unintentional) effort, but it is significantly better than the Java situation.
- Extension functions have allowed us to add functionality to platform classes, allowing for a more natural coding style and eliminating the need to create utility classes full of static methods to accomplish those tasks.
- Kotlin makes it easy to write less boilerplate and more concise code, so we can spend more time working on real functionality and finding and understanding the functionality becomes easier with less useless code stacked around it. The data class is an excellent example of this.
- Kotlin brings the power of lambdas and other Java 8 features, but still compiles to Java 6 compatible byte code which allows us to use it and continue to support older versions of the Android OS.
- The Kotlin functional programming style operators, especially for dealing with collections, fit nicely in with our existing use of RxJava, allowing more of our code to feel similar.
Along the way life with Kotlin has not been all peaches-and-cream. Having adopted Kotlin quite early in its development, before it had even reached 1.0, we had to deal with several frustrations that have since been resolved. We had a few internal debates about whether Kotlin was worth it when we hit some of these issues, but fortunately, JetBrains came to the rescue and resolved our biggest frustrations by the time 1.0 was released:
- Incremental compilation was not available from the start, meaning that compile times got quite long as we added more and more Kotlin code.
- Originally the debugger had a hard time figuring out which lines were executing, and would not break or step into lambda functions.
Where it falls short
There are still a few places where Kotlin falls short of Java. Hopefully the announcement of Kotlin as a first-class language for Android development will mean that many of these get resolved soon:
- No support among static code analysis tools (e.g. Fortify, SonarQube, etc.) means we lose out on the types of automated feedback these tools provide.
- Jacoco coverage is not as perfect on Kotlin files as it is on Java files
- Android Lint tool does not support Kotlin
- The latest and greatest android dev tool features are sometimes not supported on Kotlin right away
By the way, if you’re interested in working on our mobile team, we have several positions open; come join us and work in Kotlin everyday.
- Senior Software Development Engineer
- Software Development Engineer II
- Software Development Engineer II