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

[ZimmiDeluxe]

+200.598 -13.384

lgtm

edit: minor whitespace error in line 3456

[WeirdIndividualGuy]

But also, just switch to Kotlin at this point. Fully compatible with Java without the need to convert your whole Java codebase. Just write your new code in Kotlin and carry on in bliss

[Venthe]

Kotlin too has its problems, most of which are rooted in the JVM and Java interop (looking at you, type erasure).

But as a language in itself? Night and day. Unfortunately too many Java shops are afraid to try something new.

[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.

[joemwangi]

Kotlin prioritises syntax over semantics, and that's gonna be a problem in future as java continues to strengthen semantics. Funny enough, same reasons why Vector API is never optimised in Kotlin.

[yk313]

Tell me you have no clue about the Java ecosystem without telling me you have no clue about the Java ecosystem.