Introduction

I’m a Java developer for more than seven years and I have been always fine with it. Since a few years I’m also developing Android Apps and this community is hyping the language Kotlin. I read a lot about Kotlin, so I started to check out what this hype is about. After writing my first App in Kotlin, I must admit that Kotlin is the next generation of Java. Due to my revelation about Kotlin, I would like to share my thoughts why I am thinking that way.

Spoiler alert: I saved a lot of boilerplate code without having any disadvantages, e.g. bad IDE support, worse debugging nor high effort to configure my first Kotlin App. With AndroidStudio or IntelliJ, I can even copy code from a Java class and paste it to a Kotlin class and I get Kotlin code. Nice!

Keyfacts about Kotlin

  • Like Java, it’s an object oriented language and statically-typed
  • Kotlin classes are compiled to Java byte code
  • I can use all my favorite Java libraries
  • It’s not limited to Android

Get rid of stupid characters

I like to improve a given Java snippet by Kotlin. I gonna show up the syntactic sugar step by step, so that you are not lost at the good parts.

No need to write ;, new or void. Write : instead of extendsWhich visibility modifier is mostly used in Java? Public! So by default, defining something without a modifier in Kotlin means public!

Don’t repeat yourself by mentioning ArrayList in the declaration and initialization. I gonna tell you later what val is about.

Turn the return type of a method around. Declare the parameter name before the type and separate these with :. We need to write fun before the method name. To make this clear: fun is the keyword for functions. We do not write fun just for fun.

Every Java class has a constructor. Sometimes you don’t see the default constructor, because it will be generated, but there is at least one. So Kotlin has a nice syntax for that. You declare the first constructor behind the class name and you should define which parent constructor you like to override. Notice that you don’t repeat the class name and yes you can have more than one constructor in Kotlin, but this is another topic.

For the first time, we have valid Kotlin code! Last but not least, for single line method you are able to write the complete method in one line and you can remove the return type. The return type is the type of the called method.

What happens with the code? From 16 lines Java, we get 8 lines Kotlin code. This little numbers game shows, that we need less code for the same functionality. Now we can go to the next level.

Why should I write tests for getter and setter?

Hopefully, nobody writes tests for that. Why? They are more or less boilerplate code, so many developers ignore them. Good IDEs are generating this code for us. No reason to test them. I go even one step further and ask the heretic question: Why to write them? You do not write getters and setters in Kotlin. The property has the ability to read it val or to read and write it var. If you are calling a Java getter method inside Kotlin, you are able to write it like you wanna access a property. The compiler gives you feedback that you can’t set a val.

 

What is the best singleton implementation?

One of the simplest singleton implementation might be this one.

But if you are using this implementation what happens on the application start? All singletons will be initialized. This can consume valuable runtime and memory even when they are never used. So a lazy singleton would be a better solution.

Better solution, but good enough? Not really. The check if is inside the synchronized block and under load you have a bottleneck. Next try.

More code, better solution. My personal favorite solution is the singleton holder pattern. It’s a property of the Java classloader, that this will work. The inner class is loaded only when it is called.

Over the years I have discussed this topic with many developers and I do not know how many hours I have spent with it. For the JEE developers, yes I know that you have an annotation for that. In Spring you can define the scope. So lets see how many code do I need in Kotlin. Firstly, we start with a normal class.

Yes it’s valid Kotlin code. Remove the word class and write object.

LazySingleton is now an object, actually one object. No discussions about singletons anymore, no frameworks. The language has the power! By the way, it’s lazy.

Who needs builders?

Imagine you have a constructor with many parameters. Sometimes I don’t know what was the third one? The solution in Java is to use builders.

Now we are able to see the value of each parameter. For this benefit we need to write a lot of code. Let’s take a look on the Kotlin side.

It seems that we have the same problem, right? Not really. In Kotlin you are able to write the parameter label in front of the value. With labeled parameters you can also change the order of them and with defined default values we can leave off parameters.

Who likes to write delegation methods?

By using the keyword by you are able to delegate all methods of an interface to an object and you can override methods. A simple solution to implement the decorator pattern.

Do you like optionals in Java?

To be honest, I hate optionals until I’ve seen it in Kotlin.

In Java you need to wrap objects and thereby more code. This object can be null and the compiler ignores the error.

Add ? after a parameter or a return type to mark the value as optional. Without ? I’m not able to return null. No wrapping of objects needed and it’s save at compile time.

Wrapping a framework class is no fun!

Sometime you get to the point where you would like to add functions to a framework class. The solution in Java is wrapping it or creating a util class. In Kotlin, we write extension functions.

Do you have seen a wrong written equals, hashCode or toString method?

I’m sure you have. So let’s see what Kotlin can do for us. For sure, we can use Guava or Apache Commons and their builders to write this methods. Maybe there is something like Lombok integrated in the Kotlin language generating these methods? No, much better! This isn’t necessary because only the keyword data is required in front of your class.

Last but not least, do you like it?

Hopefully, I inspired you to try Kotlin and you can make your own experiences. If so, Kotlin has plenty more stuff to discover, like inner classes, delegated properties, sealed classes, ranges, inline functions, control flow, type aliases, destructuring declarations, and so on. Just click here to check out more benefits of Kotlin.

Leave a Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close