Why I abandoned Java in favour of Kotlin

I’ve always been a huge fan of Java. I started my career as a PHP developer and
soon after that I was forced to work in perl in another project. With PHP’s
consistent brokenness throughout the language and perl’s (alphabet-soup-puke)-like-syntax,
getting into Python two years later was a huge improvement. However, certain things still
irked me (which at that time I just couldn’t put into words), but it was there,
like a splinter in my hand that would not go away.

Eight months into the Python project, I had to build a system in Java for a freelance
project. I had no idea about how to get started, but the more I started messing around with it,
the more I loved it. It was like watching poetry unfold and an orchestra perform a
software ritual right in front of my eyes. As an ex-Delphi developer,
who became accustomed to code that reads almost like English, the ceremony
Java provided was beautiful and I was hooked.

Let’s say you are an opera singer performing the same play every day and every night,
after some time, you get tired of performing the same ceremony every day and just
want to get down to performing - screw the announcements, screw the pre-show drinks,
screw the credits, screw the standing ovations you just want to sing, enjoy the singing
and not get bogged down by everything else.

For me, the case with Java, was similar. I enjoyed writing code in Java, but all the boilerplate bothered me. You'll see in the next few sections — how then, my intro to Kotlin was a breath of fresh air.

It was quite strange back in the days when Java introduced a 4 letter extension,
.java, when every other file-extension at the time was only 3 letters long.
Kotlin cuts it down to two letters, .kt, almost as if they're making a statement saying,
"we're tired of boilerplate".

Now let's check out some interesting use cases where Kotlin outperforms Java.

Main method

Look at all the ceremony Java gives you before you get to write a single
line of code whereas Kotlin gets straight to the performance!

Kotlin:

Also note the lack of semicolons in Kotlin! Semicolons are optional in Kotlin and can be
used if you want to write two lines of code on the same line, otherwise you can just ignore it.

Unlike Java which forces you to use double-quotes everywhere, you can use triple
quotes in Kotlin! Triple quotes allow you to put anything in there without having to escape
strings, let me demonstrate …

Java:

String html = "<div class=\"text\">" + s2 + "</div>";

Kotlin:

val html = """<div class=”text”>$s2</div>"""

Note the $s2, this allows you to place any Kotlin / Java value directly in your String without
having to break the string and without having to plus parts of strings, this is really awesome!
Alternatively, you can also use ${} which allows you to do things to that value inline, like
${s2.trim()}.

Getters and Setters

Java forces you to use getters and setters everywhere to encapsulate private variables;
in Kotlin, anything that is not private, will automatically be exposed via properties
making your code more concise and readable - this feature alone got me to try out Kotlin.
Furthermore, the null-safety in Kotlin is beyond awesome. If you’re a Java developer,
you’ll probably be familiar with endless null-pointer exceptions in your logs or
bloated code that does endless null-checks, let me demonstrate with an imaginary HTML class.

Kotlin:

Notice the lack of getters in Kotlin (getting the job done without the ceremony),
the ? does the null check for you and returns null at any point the ?
encounters a null and the elvis operator, ?:, checks if the result is null
and if so, offers a default value.
Null checking in Kotlin is just sooooo much better than Java.

Method extensions

It really closed the deal for me, in Java you have gazillions
of helper classes, just think Apache Commons for example or java.utils.Collections,
let me give a simple example ...

Now every time you want to make use of this helper function, you have to do use the Helper
class which bloats your code pretty quickly.

System.out.println(Helper.stripUnwantedSlashes(text));

Kotlin fixes this by allowing you to extend the String class injecting your own method.
Note that I don’t need to do a null check on input, by defining it as type String,
the compiler won't allow it to be null; it won't even compile if it can be null.
If you want to allow null, you need to define the type as String? instead and handle
the null, otherwise, once again, it won’t even compile.

So instead of doing Collections.sort(mylist);, you can get straight down to business and just do mylist.sort()
Instead of bloating your code with Integer.parseInt("1"), get straight down to business and do "1".toInt()

Smart casting in Kotlin

This is another awesome feature that you don’t get in Java!

Following is a Java class that we'll extend, and use in both Java and Kotlin:

To make use of this class in Kotlin, you can either do what Java did and set the variables
individually, or you can passs the variables into the constructor or you can make use of
named parameters (the one which I prefer most)

Kotlin (option1):

Kotlin (option2) (notice that we can skip the last parameter since it has a default value):

val user2 = User("Graham", "Spencer")

Kotlin (option3) (notice that we can now pass in the parameters in any order):

var user3 = User(lastName = "Spencer", firstName = "Graham")

Methods in Kotlin also allows you to either call them via sequential arguments, or named
arguments. The latter is great for when you want to make a method call much more readable,
example, which looks better?

Using named parameters, you can even omit parameters that does not make sense to provide
(assuming you provide default values for them in the method declaration)
instead of providing empty strings or null. How many times have you seen long strings of null
being sent into a method and not even knowing if the method will handle it correctly?

Java:

findUser(null, null, null, 33, 40, "Mr");

Kotlin:

findUser(title="Mr", minAge=33, maxAge=40)

Operator overloading

This is something Kotlin has which Java does not! There’s been
many attempts to get operator overloading into Java, but the founders seems to
kick back against it. Operator overloading is a feature I enjoyed very much in
Python and I’m happy to see that Kotlin has it as well.

Instead of writing a.contains(b) in Java, you can overload the contains
method or use method extensions to inject a contains method which will
allow you to write Kotlin a in b
And this can be done for any operator that you can apply on an integer, like +, -, ++, etc

Better Switch Case

Haven't you always wished for a switch case that is a little more powerful?
Java’s switch case is really simplistic, Kotlin gives you when which allows
you to do anything an if-else can do, without the boilerplate.

The first question I asked on Kotlin's Slack channel (which is very active by the way) was
about whether Kotlin offered something similar to Dart's double-dot operator and some
guy told me that I can use DSLs to write my own .. syntax, but he would suggest
I stick to with. With allows you to switch the scope, let me demonstrate.

Without with, you'd have to type user1 out every time and if you had nested properties,
you'd have to chain user1.a.b.c.d.e them which reads very hard when you're integrating
into complex APIs with many levels of nested objects.

Getting rid of equals()

I think the biggest win for Kotlin is getting rid of having to use equals everywhere!!!

In Java, when using == on objects (even Strings), you are comparing pointers,
something which I've never seen anyone use in any real-world code and instead you are forced to
write string1.equals(string2) everywhere.

Kotlin decided that since hardly anyone ever wants to compare pointers, why not make ==
actually compare values and instead, if you REALLY want to compare pointers, use ===.

So instead of user1.firstName.equals(user2.firstName), you can write user1.firstName == user2.firstName.

To existing Kotlin users, I know I know, I'm just shaving the tip of the iceberg here. There's plenty
more to cover, but to cut a long story short, if you're already a Scala developer and are liking it,
you'll probably not find many new things in Kotlin that you don't have already (except for
the zero-overhead null-safety). But if you're a Java developer and are tired of the boilerplate and
all the ceremonies before you get to do any real work, then Kotlin is for you.

Kotlin is literally a better Java and I've already said goodbye to Java many months ago,
not writing any new code in Java. For existing Java projects, I simply continue
writing all new code in Kotlin while keeping the old code in Java, and keeping them both
in the same project.

33 comments

I'm currently looking into Kotlin and my plan to ditch Java is getting delayed. But with more and more I read about Kotlin, I grow more and more into it. As I mentioned before, it wouldn't be long before I left Java for Kotlin, and thanks for putting out all information which I needed.

The most interesting thing is, how quick I can write the same code in Kotlin with far more less code. And this is what I was looking for. Another good thing is, it is coming under JVM family IIRC!

Once again, thank you for writing this, so that people like me, who thought Java was the end of the world can get more idea about this Insane language!

"Smart casting in Kotlin" is biased. In Java there's no need to cast objects to Password nor to Username since getValue method is declared in the base class.
In order to improve the example, some methods specific to Password and Username should be added.

I used to code in Java for a couple years and really never had any love for it. I did find JavaScript to be much more fun for me, although it is lacking in many aspects as a robust language. Python was something that really had my attention but still to me was not complete when comparing to Java. Kotlin really caught my eye and actually got me back into the Java realm.

Great article about some of the many questions I have been looking up answers for.