DEV Community

Discussion on: 10 reasons to switch from Java to Kotlin right now!

190245 profile image

This interests me for a number of reasons (that I can happily get into, if appropriate).

I was going to pick through your list, and post a response from the Java perspective, but lets cut to the chase:

if a large number of boilerplate things are included in the language, and you do not need to constantly think about them, the development process becomes simpler, the number of errors is less.
Enter fullscreen mode Exit fullscreen mode

Assuming that is your motivation for the list, Java boilerplate can be removed in 3 ways:

  1. Frameworks (eg, Spring)
  2. Lombok / later versions of java (where data classes are supported, and val/var are part of the language)
  3. Custom annotations.

Then there's this:

But you need to think about the code style more often, because without it you can screw a lot.
Enter fullscreen mode Exit fullscreen mode

Forgive me, but code style is an internal discussion, and a document. That produces a formatter (IntelliJ will work with an Eclipse formatter export, etc). That even deals with your "one line method" claimed benefit (our formatter forces methods to one line, if the body of the method has one line, overriding our line length constraints).

I genuinely get the impression, and I'm sorry in advance if it's incorrect, that there's motivated reasoning behind this post - you like Kotlin, therefore everyone should at least try it.

Since I manage a Java development team, and one of my developers semi-frequently (and half jokingly) says things like "this would be easier in Kotlin" - I'm genuinely interested to hear concrete business benefits to using Kotlin over Java in the development cycle. My starting premise: more developers understand Java than Kotlin, so hiring people is easier.

kgunnerud profile image
Kenneth Gunnerud • Edited on

About the same reasoning I have. We use Spring + Lombok and it solves a lot of the pain points (although some remain). Kotlin does enforce better guard rails (null-handling for example), but at what cost?

When it comes to features that Java has implemented after others have shown how it can work (e.g. instanceof, loom vs coroutines (I know, not out yet), record types) I do have to say I like the Java version better? Might be a preference but it seems that Java is slowly catching up while Kotlin in the near future has to make some hard choices on how they wish to do things (ref the reddit article posted earlier highlights this in a good way).

Although, your post about LTS further up I am less sure about but I guess that also might depend on context. We run Java 16 just fine in production for mission critical applications and have no issues with it. No service agreement either, as long as we have a robust set of tests and can deploy at will with good monitoring, we have seen no issues with this over a long period of time (not always Java 16 but keeping us at the latest version).

I know very little about the practical meaning with LTS (I've understood its more about backporting bux fixes from latest) but I might be wrong here so please correct me if I am.

190245 profile image

The "Kotlin cost" - from my perspective, is that I already pay Java developers. Why do I need them to go through the cognitive complexity of learning a new syntax, if we're just going to run it inside a JVM anyway?

That, and Graal looks really interesting, as soon as MS sort out SQL JDBC compatibility, though I know that's on their roadmap. I haven't a clue what native compilation would look like in Kotlin, and the benefits of native compile far outweigh the niceties that Kotlin may bring to the table... though, that's diverging from the topic a little... and Graal will likely force us to stay a little behind the JVM release cycle.

LTS - for us, at least - isn't about "can I run this in Production." It isn't even about the level of support offered. It's more about buying time to weigh up options when avoiding vendor lock-in situations.

For an example there, we still have a large number of projects that run in a very specific build of Java 8. At least one of them, for reasons I haven't yet fathomed, will happily compile in 9... but then it refuses to run. Even when you ask javac to give Java 8 compatible bytecode. Then, during the our future migration of that project, I need to worry about reflection API changes within the JVM over time, etc etc. Plus we have dependencies to worry about, like our Tomcat version and which Servlet API it's using, or can work with and not break other dependent projects...

Sometimes, it simply makes more sense for legacy projects to stick with an LTS. Then when that's approaching EOL, we can look at "is it more beneficial to just bin that project, and re-write it?" - which also opens options for "should we do this in Kotlin/dotnet/Java/JS/C++ etc and which of those options gives the best ROI? Which team has the skillset to do that before EOL? What new features of these languages do we want to benefit from?"

Equally, our build pipeline is really simple to switch between Java versions and see if a project works in a different version... but that's why, ultimately, the language & version is a decision based on what's best for the business, not what makes developers feel cozy & warm (there's better ways to make developers happy, rather than chasing the latest tech all the time).

I mean, I still read the JVM release notes and geek out about upcoming changes, and share those around the business...

Thread Thread
kgunnerud profile image
Kenneth Gunnerud

Jepp, and as Java gets more features anyway, many things will get better. So personally we have not switched although I do from a developer perspective like what Kotlin has done, but from a broader view we have not swapped although some people want to, with the same reasoning as you have combined with the fact that Java is moving along rather fast now (and many of the small things can be fixed with frameworks/libs anyway).

Okey, I understand the premise with LTS for your sake then, thanks for clearifying.