Article summary
Despite its many flaws, Java is a fantastic language for a variety of reasons. It’s portable, runs on every device and hosting provider, and is easy to learn. It even has pretty good performance in many aspects due to its just-in-time compiler (which has been recently updated!).
On top of that, it’s also incredibly popular. While popularity definitely isn’t everything when it comes to programming languages, it’s still important. Expertise in Java makes it easy to find new jobs, since there are so many apps built on it. Having an app in Java makes it easy to hire new developers, since so many people know it. The popularity also means there are extensive, well-documented, and supported libraries and frameworks. This ensures there is basically a solution for every common problem you run into.
With such a long list of accolades, obviously you should never use this language ever again.
I’m sorry, what?
See, there’s this new language on the block called Kotlin. Well, relatively new. Google officially started recommending Kotlin over Java for Android development in 2019, which really pushed the language into the spotlight. Over the next few years, it received a lot of polish, to the point where it became an extremely attractive option for more than just Android.
The key aspect to understand about this is that Kotlin is fully interoperable with Java. That’s right, it literally compiles to the same bytecode that Java does, down to outputting the same .class files. This means you can drop your Kotlin binaries in the same deployment environments as your Java ones. Even better, you can ADD Kotlin code to an existing Java project with minimal effort. A small amount of additional configuration, and you’re good to go!
Okay, but why?
There’s a long list of features that Kotlin improves on over Java. Some are small or syntactical in nature, like scoped functions, named parameters, and improved generics. Some are large or change how code is architected, like coroutines, nullability, and companion objects. Still others are simply changing the default usage of things (and making them more well supported), like immutability, inheritance, and exception handling.
The list goes on, and there is so much detail in each of these that they warrant their own full articles. I’ll be expanding on these in future parts of this topic, but for now I want to cover why NOT to switch to Kotlin. That is, what conditions would prevent you from benefitting from it, or at least make the cost/benefit analysis more complicated.
Fair enough, why not?
Part of what makes Kotlin so awesome is that it adds and changes a lot from Java. While it restricts many things shown to be problematic over the years, it also adds the capability to do many things that aren’t possible in Java or that require a lot of boilerplate. This sounds like a good thing, but the bottom line is writing Kotlin is quite different from writing Java. If you try to write it exactly the same, you’ll end up with a variety of messes that can be worse than if you just wrote Java in the first place.
This means your team and product need to be in a position to learn half a new language. The upside is that you can use all your existing frameworks (many of which now have first-class support in Kotlin, like Spring).
Additionally, as mentioned previously, Kotlin adds several powerful new tools. It can be written in a less object-oriented and more functional style, for instance. It supports powerful tools for async and concurrent programming. If these aren’t used carefully, they can cause bugs and performance issues your team might not be used to handling. The bottom line is that it can be quite different from how Java is written at times, and often more complicated. That is the price for a more powerful language, but it’s still a cost.
It’s also worth noting that some of the benefits of Kotlin are diminished if you have heavy interoperability with Java. For instance, Kotlin has greatly improved nullability handling, but that information is lost if you make a pit stop in Java code along your call chain. This isn’t a reason NOT to use it, just that you lose some benefits. The more you migrate to Kotlin, though, the more benefits you gain.
So should I do it?
I think the answer in most cases is “yes”, but there’s definitely room to consider the cost/benefit of it. If the downsides aren’t a big issue for your situation (new product, or new team, a team eager to learn, etc.) then I think absolutely yes. But, if these downsides are a major problem, then maybe not. If you’re not sure, stay tuned for future parts as I do deep dives into specific improvements Kotlin makes that should help sway your opinion. Some of them are going to be very juicy and will absolutely blow your mind.