Java vs Kotlin – which one will prevail?

Author Ivan Anić
Category Development
Date Aug 15, 2019
6 min read

If you’re here, you’ve probably heard a lot of praise about Kotlin, the new #1 official language for Android development, and the new big thing to replace Java.

Built to address Java’s flaws, and also targeting the same JVM, Kotlin is a concise and neat language that really does look like a worthy opponent in this battle.

Since its official release in 2016, Kotlin has seen explosive growth, and has achieved more than most programming languages, especially if we take into account that it’s set against Java, the first language to pop to a developer’s mind, and the language that, even after 23 years of existence, holds the first place according to TIOBE index.

First and foremost, why Kotlin?

Kotlin is the cool kid that showed up and immediately made everyone like it. With an abundance of selling points, including less boilerplate, null-safety, data classes, extension functions and much more, it has gained a lot of sympathy from the developer community.

It is easier and faster to write, it’s concise, expressive and safe. It generates the same JVM bytecode as Java, thus making the two completely interoperable, even within the same project. The development has started in 2011 by JetBrains, purely out of the company’s practical needs, and 5 years later the version 1.0 was released.

Just a couple of years after that, Kotlin has become one of the most loved programming languages.

It is often deemed as a threat to Java, especially for Android app development. According to a short JetBrains survey among Kotlin users, 66% of developers stated that they target Android development, compared to 55% on JVM. Moreover, Google has officially named it the #1 language for Android app development, so it is clear that Android is pushing the development of Kotlin.

Is it really black and white?

If you have some development experience, you will see that some of Kotlin’s features are double-edged, depending on the scenario. So we have to ask ourselves, is the praise justified?

Null safety

Kotlin’s biggest selling point is the null safety it provides, fixing the “billion-dollar mistake”. When preparing to dive into Kotlin, you will get convinced that you will not see the notorious NullPointerException ever again. However, when you actually dive into Kotlin, you will also find that nulls are often used – it’s just the language design that forces you to think of nulls all the time. Thus, nulls in Java are also perfectly handleable, Kotlin just reminds you of that. And it’s not just the reminder, it will even throw compile-time errors, even though you would sometimes want to purposely keep a part of code null-prone, and see an exception if it needs to be seen.

Data classes

More boilerplate – gone! Getting getters/setters, hashcode(), equals(), toString() for free with just a single keyword? Brilliantly, language designers gave us just that with a single construct – a Data class. However, data classes are final, hence not really usable in a core database structure where you would wish to use inheritance, for example.

Rich standard library

The deeper you delve into Kotlin, the more neat and helpful functions will you find in the standard library. Even after a year or two of using Kotlin, you’re guaranteed to stumble upon a neat new way of writing something.

While providing us with so many aces up the sleeve we can use, language designers haven’t thought everything over thoroughly.

While for some things, like logical operators, you can choose between multiple different ways of writing your code (|| – or, && – and), some things feel a bit limiting if compared to other modern languages. For example, within the vast variety of helper data structure initialisation methods (listOf, mapOf), there isn’t a way of initialising lists and maps with the standard, well-known [brackets] and {curly braces}. Some other things could’ve been left in the language without harming anyone; for example the standard Java bitwise operators, and the ternary operator, as well.

Things to think about

In addition to these, there are some other issues you should take into account before switching to Kotlin.

What does Java represent?

Some say that Java’s syntax is very complex. No, it isn’t. Yes, it is more verbose than Kotlin per se, but its explicitness helps to understand the source code better. With that argument, we could also argue against C++, which is also one of the most used languages to date and has proven great for a whole new set of use cases.

A lot of libraries, tools, and apps are written in Java. Java is not only the language, but the whole ecosystem together with JVM, libraries for virtually anything, static analysis tools, etc. These have all been written and optimised for Java, which you may have to adjust to.

The adoption process

If you’re switching to Kotlin, it may cost you some overhead in the beginning, while learning the language. Although easy at first, Kotlin is, being more open, more diverse as well. It gives the developer the opportunity to be expressive in different ways, and offers a lot of syntax sugars and helpful tricks which you may find yourself learning about even after a year or two of developing.

Most of the materials online are still targeting Java, and it is still way more popular on StackOverflow. This can also affect your learning curve, especially if you’re diving into Kotlin without previously knowing Java. In that case, learning Java is still a plus for your career due to its ubiquity and platform-agnostic nature, and you can easily find various educational resources, best practices, etc.

Be ready for changes

Even if you do fall in love with Kotlin, you may miss some of the Java features which Kotlin doesn’t have, such as static members, the ternary operator, checked exceptions, primitive types, etc.

Despite working brilliantly together, especially in Android Studio whose developers are the same as the language’s itself, there are still interoperability flaws, Kotlin specific bugs and terse Android Studio warnings which may cost you some nerves.

With great power comes great responsibility 🙂

It can easily happen that you take the verbosity elimination too far, thus making the code even less readable than its “terrible” Java counterpart. Kotlin allows the programmer to be more concise, but if you aren’t as experienced, it is easy to go too far with boilerplate elimination, and in the end, produce a code nobody (even you) will understand in a month.

Moreover, less code doesn’t necessarily mean less compile time, according to some (e.g. OkHttp’s Kotlin upgrade).

Our experience

We switched to Kotlin gradually, firstly developing some simple features within existing apps in Java. After going through books, articles and tutorials, we felt competent enough to try it out. It wasn’t long before we got a grip on it, although the switch did require extensive googling in the beginning. Now, a year later, our Android team is 100% Kotlin, and we think it fits our needs perfectly.

To conclude

Don’t google “Kotlin vs Java” blogposts, and listen to someone else’s verdict. Albeit claimed resolved (in Kotlin’s favor), this tight dilemma is so situational – you really have to make a conclusion for yourself. A lot of developers will say different things, especially since the Java language is so widespread, enabling you to make virtually everything, with thousands of different tools and libraries. Furthermore, since most of the developers target Android, they compare Kotlin to the ancient Java 7, where not even optionals, streams, and lambdas are available. It is a different comparison than Kotlin on desktop/servers, where Java can be used to its potential.

On the other hand, Java is evolving as a language as well, in parallel with other languages and the community’s needs. Therefore, each new update will, for somebody, be another reason not to learn a new language, together with a whole new set of tools and libraries.

To be able to seriously compete with Java, Kotlin needs to further mature, in terms of compatibility and support, learning materials and popularity in general.

Bear in mind that Kotlin is just a language, a different way of expression. It can be easier to understand and code, but for corporate needs, it’ll be much easier to find a Java expert for your team than a Kotlin expert. After all, it’s the product(ivity) that’s important, not the tool itself.

So try one, try the other, see for yourself. 🙂

We’re available for partnerships and open for new projects. If you have an idea you’d like to discuss, share it with our team!

Subscribe to our newsletter

Subscribe now and get our top news once a month.

100% development, design & strategy.

100% spam-free.

    You're now a part of our club!

    We got your e-mail address and you'll get our next newsletter!