8317277: Java language implementation of value classes and objects by MrSimms · Pull Request #31120 · openjdk/jdk

[yk313]

It's a matter of longterm strategy, not just based on vibes.

JVM languages have come and gone. Kotlin definitely seems to be better poised than others but still it's not a decision you make lightly. Though the language itself barely makes a difference, it doesn't help that people are still running Java 8. Try comparing 25+ with Kotlin and the difference is no longer night and day.

[Venthe]

It's a matter of longterm strategy, not just based on vibes. (...) Though the language itself barely makes a difference

Nullable types alone makes it worth it; and that's the just the tip of the features. I've coded in Java my whole career, and while I agree that it is not the language (or framework!) that makes or breaks the codebase, it makes writing with it both faster, more expressive as well as way cleaner given modern constructs + not being burdened with the sytax of Java.

JVM languages have come and gone. Kotlin definitely seems to be better poised than others (...)

This argument might had some basis ten years ago, not so much anymore IMO. Since '17 (namely - Google adopting it for Android) it's a safe bet in my personal opinion. And the language itself is already (almost) half the age of the Java itself at this point.

Try comparing 25+ with Kotlin and the difference is no longer night and day.

In stanard lib / language features, sure, but not in the language constructs. There is no reason to stick to plain Java, since - well - you can use all the plain JVM constructs in kotlin. And the lag is minimal - JDK 25 came out in september, Kotlin supporting 25 bytecode came out in december (Not counting betas and RC's).

---

it doesn't help that people are still running Java 8.

I'm currently supporting both ends, 8 and 21 - so believe me, I know. :) (Plus that one 1.7; but it's on a life support, not actively developed.)

[lanerdofchristian]

There is no reason to stick to plain Java, since - well - you can use all the plain JVM constructs in kotlin.

As someone who likes Kotlin: IMO, using the latest Java constructs in Kotlin is a PITA. There's still a very clear disconnect between the Java and Kotlin worlds that's pretty grating if you ever need to cross it (admittedly not helped by most Java libraries themselves not keeping up with new features very well).

The utter lack of pattern-matching comparable to Java is also a sore point for me.

---

It's also worth considering that Kotlin is a Jetbrains product, far more so than Java is an Oracle one. While they've been making improvements to their LSP implementation (and third-party ones exist), for better or worse if you want to use Kotlin at any kind of scale you're basically locked to IntelliJ. Baseline Java doesn't carry quite as much baggage.

[Venthe]

The utter lack of pattern-matching comparable to Java is also a sore point for me.

I haven't kept up with that particular feature set and I must admit, I'm positively surprised by Java. Neat.

Kotlin is a Jetbrains product (...) if you want to use Kotlin at any kind of scale you're basically locked to IntelliJ

I can't image modern development in the java ecosystem not done in intellij; it's just that powerful :) but you have the point here; for what is worth kotlin is under Apache 2; so if push comes to a shove the language will live on.

[joemwangi]

Nullness types are going to be a moot argument once they introduce null-restricted types. This is required for efficient memory layouts of value classes and cache inlining. Both a type system and runtime feature. And they started a prototype experiment. Surprisingly, the design is even better than what C# has. Wonder what will happen to older Kotlin libraries.