Kotlin to the rescue

Posted on 6 January 2017

If you are doing any kind of Android development, you are stuck on Java 7. Most importantly, that means no lambdas and higher order functions. And it may be some time until we get full Java 8 support on Android. But, luckily for us, guys at JetBrains (makers of IntelliJ) didn’t like some features in Java so they decided to roll out their own language that compiles to JVM bytecode. The language called Kotlin. I’ve been using it every day for more than 6 months, and I can say that I like it. I like it a lot. It’s stable, can be used alongside existing Java code and support for it in IntelliJ and Android Studio is excellent.

I want to go over some features of the language that make JVM/Android development more fun. Basic knowledge of Kotlin and Java is required.

Reified generics

Java’s generics are implemented with Type erasure. A process where all generic type information is intentionally dropped during compilation. Yes, it ensures backward compatibility, but sometimes it can be a real pain. How many times you wished you could do something like this:

Lambdas and Higher order functions

Functions are first class citizens in Kotlin. This goes hand in hand with lambdas. You can declare a function type variable, functions can accept other functions as arguments and they can also return functions. Example, a function variable that accepts an integer as argument and returns a boolean value. The variable is initialized with a lambda function.

Extension functions

Taken from C#, they enable you to add new functions to existing classes. Not only can you write extensions for your code, the standard library comes with loads of Iterable extension methods. Just one example will make it clear. In Java, if you want to get the first item from a collection that satisfies some boolean condition, the code looks something like this:

No checked exceptions

Some people like them and some don’t. I’m in the latter group. Most languages don’t have them and it looks like guys at JetBrains also think that the language shouldn’t tell you how you write your code.

String templates

No covariant arrays

Arrays in Kotlin are invariant. In Java they are covariant. Making arrays covariant at the time (before generics were introduced) was a good idea, but you can easily make errors that compiler won’t catch. For example, create an array of strings and an array of objects. Assign the strings to objects. Add an integer to objects and you get ArrayStoreException during runtime.

Even though there are still some areas of the language that are still work in progress, like annotation processing not working (should be fixed in v1.04) and being really slow, I'd highly recommend it.