Kotlin: Java on steroids or something more?- 19 mins
The first time I heard about Kotlin was back in 2015 and my initial reaction was like “Meh! Just another heck into Android ecosystem that would lead to disasters. I’ll pass!”. I waited and waited for the hype to die down – but it never did.
The popularity of Kotlin kept on increasing. There was something about Kotlin, there was something that’s lacking in Java, I just didn’t knew what it was and being a Java fanboy I never bothered investigating. Whatever the case was, everyone was going crazy over it. So finally the prayers were answered and Google made Kotlin an Official language for Android at the Google I/O ‘17.
The reason for my immediate disapproval was because of the huge number of half-baked platforms and tools emerging for Android during that period. Every single one of them was following the same pattern. They all started out with a bang, did some impressive demos, showed great promise, made it look like everything is going to change, eventually hit technical barriers and then disappeared forever or almost died.
While there were lambdas, optional types, easier asynchronous processing mechanisms and loads of other useful features in others; Java developers were still fighting Null Pointer Exceptions and writing tons of boilerplate crap everyday.
Kotlin To The Rescue
Right after the acceptance from Google and built-in support for it in Android Studio 3, I started taking interest in it. Boy I was wrong about Kotlin! Just this single demo by Hadi Hariri done at the Google I/O was enough to convert me. Learning curve is lean for anyone familiar with Java so it took roughly 2 days to grasp the core concepts and starting to write first production application.
Now I was having a good time with it (already a fan btw!), the codebase was very concise, boilerplate free and readable - in fact pretty much self-explanatory. However, still I couldn’t come up with an expression to explain that magic. Sure there were thousands of technical arguments in its favor but it was not something you’d tell your manager when trying to convince them to use it. Then recently while watching this talk on RxJS it clicked!
Programming should be more about “what”.
One of the reasons why Python is so popular in scientific and research domains is because it is doing exactly that. It enables them to focus on solving problems instead of tangling into platform specific low level details.
On the other hand we are still focusing too much on ‘How’ rather than ‘What’ to do. A developer should be concerned with completing the task at hand with few lines of code instead of fighting the issues and barriers put in their path by the platform itself.
Alright, enough ranting about Java! Let’s take a look at what Kotlin has to offer that makes it different.
Bringing Good Of All Worlds
The selling point for JetBrains has been “NPE Free Language” for the most part and why wouldn’t it be? We’re all familiar with null pointer exception jokes made on Java developers.
Specially on Android it is quite annoying when the entire application just blows up in your face due to a sudden NPE and then as a developer you’ll have to spend a lot of time going back to the same state where you were before.
.. and GOD Help you if they show up in the production code.
In Kotlin, the syntax is different for references that can hold
null and those that can not. For example, a regular variable of type
String can not hold
The syntax to allow
nulls is to add a trailing question mark after the type declaration e.g.
Now, if you call a method or access a property on
a, it’s guaranteed not to cause an NPE, so you can safely say:
But if you want to access the same property on
b, that would not be safe, and the compiler reports an error:
It doesn’t stop at this, type safe calls allows you to eliminate
if (someValue != null) blocks for nullable types with simple
?. operator which essentially means execute this only when the value is not
You can also apply an alternate logic for
null case using elvis operator which is equivalent to the
else block that follows the if not null block. The syntax for it is
?:, so your conditional code will look something like this:
This is just an overview, it’ll take at least an entire post to cover all of the type system. You can read more about it on the Kotlin’s official documentation
This one is my personal favorite so far. How much code do you have to write for a data class? And how much more do you have to add if you need to add
toString() functionality? This is your average data class declaring fields and providing that additional functionality along with getters and setters:
That’s around 70 lines for a simple POJO! Even if the IDE generates them for us, it is every difficult to maintain in the longer run. Now let’s look at what the Kotlin equivalent of this would look like:
Yes, that’s it! A single line that provide you a fully functional data object with
toString() functionality baked right into it. So now your entire package of data classes can be combined into a single Kotlin file.
More Intuitive Flow Control
if-elsestatements and there are
switchstatements, then there are Python-like
if-elseconstructs and then there’s Kotlin’s
when improves the traditional
switch operator with more readable syntax and increased flexibility for different cases. It can be used both as a statement and as an expression. Following is an example:
On a side note, just like the
when operator, the
if-else statements also return values in Kotlin.
For looping, we can use
in operator instead of less meaningful
: from Java:
Alternatively, you can use the withIndex library function:
We often write
instanceof checks before processing a variable e.g.
if (x instanceof String) doSomething(). In Kotlin, the compiler is smart enough to cast objects when it is certain about type changes. The most common use case of this feature is when you have to use a value after checking it’s type:
If you were to write same snippet in Java, you’d have to either cast
u once again in the print statement or either store the casted value for future use. In this instance, Kotlin can keep track of type and let you use it freely without caring about the type.
Oh! and by the way
as are also operators in Kotlin.
readability += 1
Here’s a scenario, you need a way to check if user is connected to the Internet. You’d find a snippet and then eventually end up storing that in some sort of
Utils class. Now this
Utils class has one more habitant along with GOD-knows-how-many other helper methods that are completely unrelated to each other and you carry this file with you in every project and making calls to it for all sorts of functionality. Sounds familiar?
What if you could simply define that functionality in a class that is related to it? Without needing to inherit from it (in case it is a
final class)? So you can have that functionality in, say
Context class and then you can simply call your
isConnected() method from your activities as if it is part of them? This is exactly what extension functions are for.
To declare an extension function, we need to prefix its name with a receiver type, i.e. the type being extended. So our
isConnected() function will look something like this:
and then you can use this from inside any descendant of
Context class as if it is part of standard library while still keeping it in some sort of
We all love lambdas, right? They provide clean and concise logical units that can be passed around as a plug-in functionality. While Java is catching up, they’re still not up to the mark when it comes to multi-method lambdas and storing them as expressions.
This is a simple lambda expression that takes two integer type values and returns their sum. There’s a lot of flexibility to them as well, for example, you can omit the method parentheses if the lambda is the only or last argument of a method.
Higher-Order Functions, something we always wanted in Java. If you are unfamiliar with the concept, it is simply a function that can accept other functions as parameters or returns a function.
This is something that can eat a lot of your boilerplate code if used smartly. For example, let’s build upon our existing
isConnected() function and create a function that accepts a block of code and executes it only when connected to Internet. This is a fairly common use case, so you may want to make that an extension function too.
When combined with extension functions and lambdas, Higher-Order functions can make your trivial tasks such as checking for the Internet or closing the database after its usage so simple that you can forget about their existence.
I found this a very impressive feature in Python that sadly lacked in Java. What destructuring declarations do is simply chop down an object into a number of variables so you wont have to fetch each of its members individually and assign them to variables.
When combined with Data Classes, this also paves way for functions that can return multiple values. Something we always wished to have in Java.
For example, let’s say we want return
message from an HTTP response, all we have to do is declare a
Data Class and return those two items as it’s members. At the other end, we can simply break them.
Default and Named Parameters
I think most of you would agree that if we had default parameters in Java, it could’ve saved us from writing countless overloaded methods. We typically write one methods that covers all the possible parameters and then write other variations for it that doesn’t do much else but delegate the call to the original method after providing an implementation for missing (or newly added) parameters.
Kotlin solves this problem. Here’s an example of extension function for
AppCompatActivity that displays a
Snackbar with short duration when the duration is not provided.
Not only we can give default values to parameters but also use them with their name, so we can call them independent of their order of declaration. For example, I can call my
displayMessage() function in any of the given orders:
100% Java Interoperability
Last but most importantly, Kotlin is 100% interoperable with Java, which means you can use both languages side by side inside the same project and call code from each other without any special treatment.
Important to mention that Android Studio 3 ships with a Java-to-Kotlin converter, that converts your Java classes with single click of a button. Save it for the time when you completely fall in love with it and decide to convert your existing codebase to Kotlin. ;)
I tried to keep this post as concise as possible and skipped a lot of handy feature such as Ranges, Properties, Operator Overloading, Type Inference, String Interpolation etc in doing so. However, I believe only those discussed will be enough to make you realize how much productivity and ease of use Kotlin can bring to your everyday development. Happy learning! :)