I hate working with Java. I really do. It makes me always feel powerless and bored. Yet I need to face it in pretty much every project I work on – one way or other. I do get the reasons of many companies to use Java, but those are based on completely different perpective than the one that I have as a programmer. In this blog post I’ll tell you why I feel so and introduce a great alternative, Kotlin, based on my experiences on Kotlin in projects varying from plain Kotlin to Spring 5 WebFlux and Android. I do hope that the things described in this post will encourage you to at least consider Kotlin as an alternative for your beloved Java.
My problem with Java
Describing everything I hate about Java would take a blog post series of its own. In this post I concentrate to the parts that I come across most often while doing web development with it.
The biggest problem of Java is the unergonomic nature of working with it and especially the ecosystem around it. Let’s take a few examples of code that needs to be written all the time while doing web development. First there are the POJOs (Plain Old Java Object) needed to model the data structure of applications. Here’s an example of idiomatic Java code:
class Person {
private String name;
private Integer age;
public Person(String name, Integer age) {
this.name = name;
this.age = age;
}
public String getName() {
return name;
}
public setName(String name) {
this.name = name;
}
public Integer getAge() {
return age;
}
public setAge(Integer age) {
this.age = age;
}
}
There is 20 lines in this model, out of which not even half declare anything useful. Let’s compare this to same model as idiomatic Kotlin:
data class Person(var name: String, var age: Int)
Okay, looks quite a lot simpler. How about the usage then? Let’s declare an array of objects of these types. First Java:
final List<Person> persons = new ArrayList<>(Arrays.asList(new Person("John", 36), new Person("Mary", 29)));
And Kotlin:
val persons: MutableList<Person> = mutableListOf(Person("John", 36), Person("Mary", 29))
Ok, so at least to me even the creation of objects seems also a lot more compact in Kotlin.
Kotlin is an excellent example of a programming language I categorize as modern, developer-friendly programming language. Kotlin is constantly releasing new versions with the most wanted features by the community. It does this constantly with small batches instead of Java’s huge updates coming every X years. In practice, Java’s latest release (Java 8) is from 2014 while Kotlin has released already once (1.1) along with multiple patch, preview and release candidate versions this year with at least Kotlin 1.2 still coming before the end of the year.
Generally speaking I do believe the less code you have the less there is to maintain. One could argue that since you have to write less code to achieve the same you must be skipping some important things or there have to be some implicit stuff (often referred as magic) that would need to be explicitly written for it to be clear. But that is not the case actually. Just take a look at the examples above, they aren’t lacking anything that is in the corresponding Java code, but they are much nicer to write and read since there is less noise around the actual thing.
Java development is also overly complex. I never was able to wrap my head around of all the Java EE stuff. Nor did I even try because I always knew it won’t be the way to go. With solutions such as Spring Boot that have lately become the standard way to do web services there has already been a huge improvement on this. Still, the solutions made by Java programmers tend to follow the same overengineering practise from the past. This isn’t something that can easily be changed. No wonder also Spring 5’s WebFlux has built-in support for Kotlin.
For me the caricature of a Java developer is a developer who is totally locked in to the way things are done in Java which is obviously the only acceptable way for him/her. They rely on XML which has in my opinion partially the same problems as Java. Essentially it is not ergonomic to use. Java developers, in my experience, tend to believe that other languages are just some kind of toy languages for pet projects and not capable of building the complex enterprise applications (whatever that even means) that they need to build. These developers always think that their application is so large and complex that it can only be solved with the one and only enterprise-capable programming language in the world – Java. Usually the services built are actually quite simple and could be implement a lot easier with some more appropriate tool like Node.js. Yet the only capable language is believed to be Java.
Okay, that is quite harsh and most propably not an accurate description of many Java developers but you get the idea, right? Still, they say every cloud has a silver lining. That is the case also for Java for which the great part is the JVM as discussed in the next section. Also the ecosystem is quite good around Java.
So how about Kotlin?
First, let me tell you what Kotlin is. Kotlin is a modern programming language by JetBrains (the company behind the IntelliJ IDEA and other IDEs among other stuff related to software projects). It continues the list of JVM-based languages such as Groovy, Scala and Clojure. Kotlin, released in 2011, is not only running on top of JVM but completely interoperable with Java. This means that companies can migrate existing codebases to Kotlin gradually piece by piece without extra hassle and still leverage the large ecosystem around Java. Kotlin can be used also to do Android development without performance hit. It also supports compilation to JavaScript for Node.js or browser apps.
But what makes Kotlin more ergonomic to use than Java? Kotlin aims to be as concise as possible and to eliminate a lot of boilerplate code found in applications written on Java. Kotlin’s home page gives great examples of all the most important benefits of using Kotlin. Since we already mentioned the POJOs, let us start with the example used already earlier:
data class Person(var name: String, var age: Int)
Wow, that is concise. So how about the setters and getters I (as Java developer) want for every damn field no matter they’ll never even contain any logic? Well, Kotlin already generated the getters and setters for us. I don’t personally find the value of getters and setters to be that great and I am happy to use public fields instead. And yes, I am familiar with the idea behind using private fields and getters/setters but I never do anything special in the getters and setters so I am happy to refactor the direct usages of public field to getter/setter when actually needed. But I’m not going to dive into that discussion now since it is out of scope for this post.
Another extremely important feature that many languages (such as Swift) have implement because of null-safety problems with languages like Java is the concept of Optionals. Yes, the Optional<T> is there finally in Java 8 but it is simply too little too late. Kotlin makes the null-safety main feature of language instead. Here is an example of how the optional code looks like:
This produces a compilation error:
var myString: String = "foo"
myString = null
while if we explicitly allow null values, this would compile:
var myString: String? = "foo" // Non-null value
myString = null
Also if we have possible null value, we can’t just call some method on it:
var l = myString.length // // error: variable 'myString' can be null
and instead we need to explicitly do a safe call with ?. instead of .. This way the result is null if the left-side of operator is null.
You can still get an NullPointerException in case you explicitly want it or some external Java code throws one but those are special cases and won’t happen by accident on Kotlin side.
One extremely annoying feature of Java has always been that it only supports Object-oriented programming. Even the very basic lambda functions weren’t possible before Java 8. Kotlin provides the basic OOP capabilities while offering great support for functional programming with features like functions as first-class citizen and encouraging usage of immutability.
Besides the features highlighted here, there are lots and lots of features in Kotlin that make it superior compared to Java. These things include better syntax, fresh take on asynchronous coding with coroutines and great tooling support by IntelliJ IDEA. One great example of the last one is the option to convert Java code to Kotlin automatically. Having used quite a lot of this it has proven to work extremely well.
Conclusions
Technology choices are always made with at least some kind of assessment of costs and risks associated with certain technology. Often heard concern is how fast the team will adapt the new technology. As Kotlin builds up on the same premises as Java it is extremely easy to adapt by Java programmers. The basic types are the same and code looks a lot same. Also the whole ecosystem built around Java is easily used within a Kotlin project. These facts combined with automatical conversion from Java to Kotlin to see how things would look in Kotlin makes the learning of Kotlin easy for Java developers.
Second concern relates to the expected future support for the technology. Kotlin is supported and used by JetBrains itself which is one of the key players in software-related tooling. There’s currently no reason to expect they would stop the development for a long time. It is also used by many well-known companies as listed on Kotlin’s home page. Kotlin is also recommended by Google to be used on Android development.
The Java-interoperability of Kotlin is also an extremely important aspect as it lets you use all of the Java libraries and frameworks. Besides that it is also possible to not only convert Java code to Kotlin but also vice versa (though not explicitly supported by the tooling) in case you want to get rid of Kotlin for good.
As a conclusion Kotlin takes the best parts of Java and combines those with a modern language with great tooling. Its advanced features allow you to write concise and clean code without unnecessary boilerplate around it. Let me know of your experiences in the comments below. Also keep your head up for upcoming posts about soon-to-be released Spring 5 and especially its new WebFlux module.
