Is Kotlin Java++ or beta of Java?

Is Kotlin just a beta version of Java and is it going to be superseded by Java and die? Or, is Java just trying to catch up from a better language but it will be never able to do this? Let’s check what is going on there!

From the birth of Kotlin to the present day

Java 8 was a big deal when it was released in March 2014. Lambdas and stream API enabled thousands of developers to start writing in a more functional style without boilerplate code as they could do before with Guava library. The first official Kotlin 1.0 release was in February 2016 between Java 8 and 9 releases (September 2017) and Kotlin already had Java 8 features (and many more) from day one.

I have been observing Java language development since Kotlin first release and happily noticed that Java is adopting lots of cool features:

  1. First and the most obvious one is var keyword (local-variable type inference) which was added in Java 10 – JEP 286.
  2. Then expression switch JEP 325 has been introduce to Java 12 and even improved in Java 13 – JEP 345. Kotlin supports this feature with when keyword but java stayed with the original switch in this preview feature.
  3. In the last Java release (13), text blocks (multiline string) support has been added as preview feature – JEP 355.

The future of Java

From the article perspective, the future of Java is Java 14 and above. There are a few interesting things coming:

  1. Records – JEP 359 preview feature in Java 14. Equivalent of Kotlin’s data class (with val as fields) or Lombok’s @Value annotation on a class.
  2. Pattern Matching for instanceofJEP 305 preview feature in Java 14. Kotlin calls this feature “smart cast” and it works from day one.
  3. Sealed Types – JEP 360 (candidate). Similar to Kotlin’s sealed classes but with support for interfaces.
  4. Value Types – “inline types” in LW2 / Project Valhalla. Available in Kotlin 1.3 as inline classes (experimental feature).

It looks like Java is really absorbing more and more features from Kotlin and it is going to replace it someday. But…

There is one thing that Kotlin will always beat Java

Null-safety – this is the true power of Kotlin. Compiler prevents us from passing null into the code which does not expect that and lets us stop adding dozens of null-checks. We don’t have to trace NullPointerException and somehow judge when and where it is a valid state, who passed it to my code and why.

I’m going to go out on a limb here and say that this is the biggest feature of Kotlin. Ultimately, this is the reason why I fell in love with Kotlin a long time ago (before official release) and even used it to implement a few distributed algorithms during my studies (my three-phase commit implementation using Kotlin beta and Akka).
The real life is not so simple as there is also platform type (the performance trade-off for JVM) but still it is a big deal.

Kotlin is doing well

There are also other indicators that Kotlin is doing great (not only related to core language features):

  1. Google made Kotlin the preferred language for Android! It was a big deal during Google I/O 2019 even though developers were able to use Kotlin for Android development without much effort before (support for Kotlin has been announced during Google I/O 2017).
    I suspect that it was mostly related to “Google v. Oracle America” battle than to the Kotlin technical advantage over Java.
  2. Kotlin has been also spotted by Spring. It is officially supported starting from Spring 5.0 and corresponding Spring Boot 2.0.


Kotlin is a great evolution of Java. It is my go-to choice when I need a high-level language which is developers productivity-oriented and it is still statically typed.

It adds support for non-nullable types on the language level which saves developers a lot of time and provides extra safety. It is clearly visible that Java tries to catch up but it is not an easy task due to backward compatibility so it requires time. For the same reason, Java will also never have so robust syntax as Kotlin.

Of course, I totally ignored dozens of other features that are released together with Java such as JVM and GC improvements. Kotlin is going to adopt and use them the same as plain Java does.

Is it worth to switch to Kotlin? In the new project, definitely yes as you can quickly write code without dozens of additional libraries like Lombok. In the old project, no. You can wait for newer Java or start using other libraries and it will be much cheaper than rewriting the entire app using the new language. After all, we write code that earns money. Sometimes two or three years in projects lifetime isn’t that long and could be worth to improve Java codebase instead of doing big-bang rewrites.

My answer

I still think Kotlin is a great language and somehow evolution of Java. So my answer is: Kotlin is Java++.
Well done, JetBrains!

I have already set up a reminder in my calendar to revisit and challenge this article in a few years. Let’s see what come true 🙂

2 thoughts on “Is Kotlin Java++ or beta of Java?”

  1. what’s your take on Kotlin’s lack of package-private? How do you organize your code without this? What alternatives to package-by-feature can you propose?

    1. I’m a fan of Gradle/Maven modules even in Java applications. Kotlin supports modules via “internal” visibility modifier. Of course, you have to be careful. It is extremely easy to create 100+ modules even in a simple application and provide unnecessary complication to the project. I saw that even in Java apps 😉

      A good balance might be using some convention – something in between modules and packages. Personally, I like to map some architecture levels (e.g. Containers or Components from C4 model) to the Gradle/Maven modules. And then, I still use the packaging technique (package-by-feature) even though Kotlin does not provide a visibility modifier for that (which is flaky in Java anyway). Then the team can maintain the proper usage of the classes during code review.

Leave a Reply