by Adam Arold

Kotlin is the new Java

If you have been a Java developer for a while now you might be wondering what to learn next. There are a bunch of languages out there which worth a look, like Clojure, Rust or Haskell. But what if you want to learn something with which you can pay the bills but it is not a pain to use? Kotlin is in the sweet spot just where Java used to be and in this article my goal is to explain why.

So what is Kotlin?

  • A home-grown programming language by JetBrains who are the masterminds behind the acclaimed IDEA IDE and a bunch of other stuff.
  • A simple and flexible alternative to Java
  • Which interoperates well with existing Java code
  • Compiles to Java bytecode
  • Runs on the JVM
  • And also compiles to javascript

If you read the docs you can see a bunch of stuff going for it:

  • It lets you achieve more with less code
  • Solve a lot of problems in Java
  • Helps you keep using the Java ecosystem
  • Lets you write front-end and back-end code in the same language
  • Gives you 100% Java interoperability
  • It does well compared to the alternatives (Clojure, Scala)
  • Adds only a thin layer of complexity over Java

Sounds cool, right? Let’s just not drink the Kool-Aid too soon and see some examples how well it fares compared to Java.

Value objects vs data classes

What you see here is a POJO with all the boilerplate:

Creating value objects is really cumbersome even with the usage of libraries like Lombok. (Lombok needs you to install a plugin into your IDE in order for it to work which might not be an option for all IDEs. It can be worked around with tools like Delombok but it is a hack at best. Read more here) At least IDEA (or Eclipse) gives you a little help with generating a lot of these methods but adding a field and forgetting to modify the equals method will lead to nasty surprises. Let’s look at the Kotlin equivalent:

Whoa! That’s quite less typing compared to the Java version. Data classes in Kotlin give you

  • equals + hashCode and
  • toString in addition to
  • getters and setters. You can also copy them which effectively creates a new object with some fields overwritten. See here for more information on this topic.

String interpolation

String manipulation in Java is painful. It can be alleviated by using String.format but it will still remain ugly.

Kotlin works around this by adding String interpolation to the mix with which it is a bit simpler to use variables in String literals. You can even call methods from one!

Extension functions

Writing decorators in Java can be tricky and they are not perfect. If you want to write a decorator which can be used with all classes implementing List you can’t simply use it in your decorator because it would need you to implement a lot of other methods so you have to extend AbstractList.

If you need to decorate something which does not provide useful base classes like AbstractList or is a final class then you are out of luck. Extension methods come to the rescue!

This method acts as a decorator for all Lists. Compared to the Java alternative this one-liner is much simpler and it will also work for final classes. Just try not to abuse them.

Null safety

Checking for null values involves a lot of boolean expressions and a lot of boilerplate. With the advent of Java 8 you can finally work around this with the Optional class but what if the reference to an Optional is null? Yes, you’ll get a NullPointerException and after 20 years of Java we still don’t know what was null. Take the following example:

With Kotlin you have several options. If you have to interop with Java projects you can use the null safety operator (?):

The code will only run after a ? if its left operand is not null. The let function creates a local binding for the object it was called upon so here it will point to If you don’t have to interop with Java I would suggest doing away with nulls completely:

If there are no nulls involved (no ?s present) it all becomes a lot more simpler.

Type Inference

Kotlin supports type inference which means that it can derive types from the context in which they are present. This is like the Java diamond notation <> but on steroids! Take the following example:

This looks almost the same in Kotlin:

Until you let Kotlin figure out the types of your variables:

or even methods:

No checked exceptions

You must have seen this piece of code at least a million times:

Old school IO in Java. Note the try with resources block! The same would look like this in Kotlin:

There are a couple of things going on here. First Kotlin does away with checked exceptions. Secondly Kotlin adds use to any Closeable object which basically:

Executes the given [block] function on this resource and then closes it down correctly whether an exception is thrown or not. (Taken from Kotlin’s documentation)

What you can also see here is that an extension function (readLines) is added to the File class. This pattern is visible throughout Kotlin’s rather small standard library. If you have ever used Guava, Apache Commons or something similar, chances are that you will see common functionality from them added to a JDK class as an extension function. Needless to say this will be good for your health (nerves at least).

Lambda support

Let’s look at the lambda support in Java:

Since there is no syntax for method parameter types we have to create an interface for it. Note that we could use Function<String, Boolean> here but it only works for functions with one parameter! There are some interfaces in the JDK to solve this problem but if someone looks at the code they might be puzzled what a BiFunction is useful for? Kotlin improves on this a bit:

Kotlin adds a syntax for passing functions as parameters: (ParamType1, ...ParamTypeN) -> ReturnType. And with Kotlin you have method and field references and you can also refer to a method from a concrete object! Using the example above I can refer to the filterBy function on a concrete instance like this:

Functional programming

Functional programming is all the buzz nowadays and with Java 8 they have released Oracle’s take on the topic: the Stream API. It works like this:

The Kotlin equivalent is rather similar, but subtly different:

There is no explicit conversion to streams since all Kotlin collections support it out of the box. Not having to pass a lambda to flatMap here is a direct consequence of this. Collecting the result is also automatic (no need for* method calls). We only had to use toSet here because we want to return a Set. Otherwise .toSet() can be omitted.

Kotlin-java interoperation

Well this can be a dealbreaker for most people but JetBrains got this right:

The interop is seamless and painless. Java and Kotlin can live together in the same project and Kotlin supplies a set of annotations (like @JvmStatic here) so Kotlin code can be called from Java without any fuss. Check here for further information on this topic.

As you might have seen from these examples Kotlin takes the good ideas from Java, improves upon them and tries to keep the WTF/minute counter to a minimum. The recent news about Google making Kotlin one of the supported languages on Android also underpins this.

Things to tell your boss

So if you want to give it a try here are some pointers which will help you when negotiating with your boss and teammates:

  • Kotlin comes from industry, not academia. It solves problems faced by working programmers today.
  • It is free and Open Source
  • It comes with a useful Java to Kotlin converter tool
  • You can mix Kotlin and Java with zero effort
  • You can use all existing java tools/frameworks
  • Kotlin is supported by the best IDE on the market (with a free version)
  • It is easy to read, even non-Kotlin programmers can review your code
  • You don’t need to commit your project to Kotlin: you can start by writing your tests in it
  • JetBrains is not likely to abandon Kotlin because it drives their sales
  • Kotlin has a vibrant community and even you can easily contribute to Kotlin and suggest new features using KEEP

So does it live up to the hype? Only you can tell. Here are a few pointers where you can start:

Originally published at on May 19, 2017.