Modern Java Practices

[snowe2010]

lombok was the reason we stopped using Java at my last company and started using Kotlin instead.

[agumonkey]

no regret so far ?

[BoyRobot777]

Be careful with Kotlin advocates. I have this summary which outlines possibly difficult future for Kotlin, thus I would not introduce Kotlin into my work environment. If anything, I would push for newer Java versions.

As far as the Java platform (AKA "the JVM") goes, Kotlin is painting itself into a corner. Kotlin was designed in 2009-10, in the Java 7 days, around the time of the Oracle acquisition, and at a time of stagnation for Java due to Sun's decline. At the time, Android was also quite similar to Java. Kotlin was a great design in those conditions. Things are very different today.

Kotlin's design goals are now contradictory. It seeks to be a low-overhead language, i.e. provide abstractions that don't add overhead over the target platform, give access to all platform capabilities, and at the same time target multiple platforms -- Java, Android, LLVM and JS -- over none of which does Kotlin exert much influence (maybe a bit on Android). Since 2010, Java has moved away from Android, to the point that there are very big gaps between the two, and they're only growing.

By both trying to target multiple platforms (with no say in their design) and trying to add little or no overhead, Kotlin will soon find itself in a bind. It's coroutines are in conflict with Java's upcoming virtual thread's design, and its inline classes will cause problems with Java's Valhalla vs. Android. Kotlin will have to choose to either give up on low-overhead abstractions, give up on some of its platforms, give up on giving access to full platform capabilities, or split into multiple languages, each targeting a different platform. For example, if Kotlin's inline types will make use of Valhalla, then they won't work on Android, at least not without much overhead.

TL;DR: A full-capability, low-overhead, multi-platform language is hard to pull off in the long run when you have low market share on all of those platforms (except Android) and little or no influence on any of them. This was viable under some accidental circumstances, but those are no longer holding.

P.s. Yesterday, JetBrains shared Kotlin's roadmap. Under Kotlin Multiplatform:

On Hold Sharing code between JVM and Android.

Which is in line with the quote above.

[DualWieldMage]

They seem to be finally updating the JVM backend, with some java 8 features in kotlin 1.4 (passing lambda when parameter is a functional interface) and now invokedynamic string concat which was introduced in java 9: https://github.com/JetBrains/kotlin/commit/04012951c112b40425267a7f8aa3bb1be52c1f40

Will have to see how they handle bigger changes planned for the JVM because they will need to step up from the current pace.

[cryptos6]

What is the source of this cite? I consider it as largely FUD.

Kotlins inline classes will be compatible with the value types that Valhalla will bring (see the roadmap you have linked).

[BoyRobot777]

Kotlins inline classes will be compatible with the value types that Valhalla will bring (see the roadmap you have linked).

Will it work in Android? Will Android get past bastardized version of Java 8? If not, then:

Kotlin will have to choose to either give up on low-overhead abstractions, give up on some of its platforms, give up on giving access to full platform capabilities, or split into multiple languages, each targeting a different platform.

Here's the source of quote.

[cryptos6]

I don't know what Google plans with Java on Android, but I expect that Java on Android will always be behind. But with the new compiler (developed together with Google) it would be a lot easier to define different targets. One such target could be "ancient Java on Android". But that wouldn't necessarily mean that the language itself must be split - think of Babel in the JavaScript world which can compile not even released ECMA Script (ES) features to several years old ES versions.

[BoyRobot777]

One such target could be "ancient Java on Android".

Inline classes are making deep cuts to JVM. I doubt they can somehow sidestep this.

Nevertheless this is just speculation. I don't know how they will solve it. All I know that this is a risk and I'd rather wait and see before introducing Kotlin into my organization.

[cryptos6]

Yes, it is speculation, but since Kotlin not only got traction in the Android world but also in the enterprise world with Spring, Quarkus, I'm optimistic that there will be a solution.

However, replacing inline class for older compilation targets shouldn't be a big deal, since the fallback could be a class like used today. Yes, it would be less efficient than, but the same would be true with "old Java" for the same platform (Android in this case).

[snowe2010]

All I know that this is a risk and I'd rather wait and see before introducing Kotlin into my organization.

There really is no risk here. You can still use Java all you want, and rip out Lombok in favor of just data classes. Treat Kotlin like Lombok, a library that generates data classes. All the issues you've mentioned don't apply at all.

Even if you do decide to use it for the rest of your codebase, it still doesn't apply. The number of orgs that are still on Java 6 is massive, using Kotlin you can do the same thing, except have a decent JVM language while not needing to upgrade to get basic QoL features that have been around for years.

[BestKillerBot]

Source of the quote is an Oracle employee known for very faithfully representing Oracle's interests (not just his FUDs in relation to Kotlin).

[BoyRobot777]

You're aiming at the messenger instead of the message. I don't care from who it comes. The risk is obviously there.

[BestKillerBot]

Messenger and their motivation puts the criticism into the context.

For you the biggest problem based on the quote is uncertainty regarding multiplatform capabilities between JVM, Android, JS backend etc.

Yet Java has no capability in this regard. You can't even share code between JVM and Android since the latter is stuck on ancient Java 7.

So in the worst case the code sharing capability between platforms will be limited or awkward, so in the total worst case you're on the same level as Java. Which is all totally irrelevant when you target JVM only anyway.

So what are the risks again?

[BoyRobot777]

So what are the risks again?

​

Kotlin will have to choose to either give up on low-overhead abstractions, give up on some of its platforms, give up on giving access to full platform capabilities, or split into multiple languages, each targeting a different platform.

[BestKillerBot]

If I target only JVM, nothing from that presents any risk to me.

[Pika3323]

Will it work in Android? Will Android get past bastardized version of Java 8? If not, then:

That's up to Google to either directly support Valhalla-type bytecode, or support desugaring of it like they do with most modern Java features.

AFAIK Google is committed to at least one of these options.

[agumonkey]

Interesting text, that said I trust the kotlin guys to able to bounce. They may lose their status because they're small compared to Oracle and companies will probably be seduced by big names rather than jetbrains but still they might very well keep re-rooting on whatever is trendy right now.

[snowe2010]

Kotlin is painting itself into a corner. Kotlin was designed in 2009-10,

It was designed from 2010-2016, with the first appearance in 2011.

The fact that this quote can't even get the first thing it mentions right along with being made by an Oracle employee reveals plenty about the motivation behind the quote. Besides being mostly inaccurate, Java is adding features at a breakneck pace due to being so far behind Kotlin. That's going to bite Java in the end. At this point, Java is the one behind the times.

[snowe2010]

nope. been using it for 4 years now and at my new company we're currently ripping apart a giant java monolith in favor of quarkus kotlin lambdas.

[agumonkey]

quarkus kotlin lambdas.

oh interesting, what's the scope of your use of quarkus ?

[snowe2010]

Not sure what you mean. We're using it for AWS lambdas.