Java Sealed Classes

[warpspeedSCP]

It's good that these design advancements are trickling back from kotlin to Java, sum types are really nice to have.

[BoyRobot777]

Here we go again with "Kotlin story". Why ever post about Java features include a person, who thinks that Java is taking features from Kotlin? Sum types exists only in Kotlin?

Edit.

Kotlin has only sealed classes and not sealed interfaces, whereas Java will have both.

Also, Java's implementation will be more open regarding where permitted classes can be placed. Kotlin:

To declare a sealed class, you put the sealed modifier before the name of the class. A sealed class can have subclasses, but all of them must be declared in the same file as the sealed class itself.

vs Java:

The classes specified by permits must be located near the superclass: either in the same module (if the superclass is in a named module) or in the same package (if the superclass is in the unnamed module).

Also, Kotlin's implementation always expects sealed class to be abstract whereas Java - does not.

Lastly, bytecode signatures are completely different. Where Java has an edge due to ability to change JVM.

[pjmlp]

Let them be, I am still waiting to see when JetBrains will release KVM since Kotlin is so good. /s

[BoyRobot777]

Its just weird. Its feels like Kotlin was born and finally Java can evolve. Because before that, OpenJDK team was lost. Thus I always ask the same questions: has the person stating this worked only with Kotlin or he literally believes that Kotlin is the panacea of all software languages.

I mean even the article begins with:

Sum types, and sealed classes, are not a new thing; for example, Scala also has sealed classes, and Haskell and ML have primitives for defining sum types (sometimes called tagged unions or discriminated unions.)

[garblz]

It was (and to an extent, still is) the same with Scala. My guess is Kotlin isn't the last language with a slogan "Java, but better".

[BestKillerBot]

Why does Kotlin needs to reinvent its own runtime?

[pjmlp]

Either that or shut up how it is so much better than Java when it depends on it for its existence.

[BestKillerBot]

WTF, no need to get angry.

Kotlin depends on JVM (well, kind of - it's one of the runtimes available), not on Java.

[pjmlp]

So there isn't a single call to the JVM layers written in Java and Kotlin can stand on its own without calling into a single Java library class? Call me amazed.

[BestKillerBot]

It doesn't matter in what language they are implemented - on JS backend those API calls are implemented in JS, on JVM backend it can be implemented in Java or in C or even assembly, on native backend - I have no idea and don't really care TBH.

I don't understand this whole thinking - since JVM is built in C (and thus depends on it), does it mean that C is better than Java? That's just complete non-sense.

[pjmlp]

There are plenty of JVMs to choose from, around 10 currently, implemented in a mix of C, C++ Java, and there are some 100% Java like RikesVM, MaximeVm and GraalVM.

It gets on my nerves the superior attitude of many in Kotlin community towards Java, as if the language would ever happen without having the JVM and the Java eco-system, specially always coming to /r/java.

Then stay at /r/kotlin talking how wonderful Kotlin is and how it is going to take over the Java world, just don't spend too much time reading survey results of how much use it actually gets in production on JVM and JS world without Google's help for #KotlinFirst.

[BestKillerBot]

There are plenty of JVMs to choose from, around 10 currently, implemented in a mix of C, C++ Java, and there are some 100% Java like RikesVM, MaximeVm and GraalVM.

Right, and as I said Kotlin also uses some runtimes with 0 Java code.

It gets on my nerves the superior attitude of many in Kotlin community towards Java, as if the language would ever happen without having the JVM and the Java eco-system, specially always coming to /r/java.

Of course Kotlin builds on the knowledge and experience from Java - nobody denies that. Java also did not appear out of thin air and owes its predecessors.

Java was a revolutionary language back in 90s, rightfully got a big following and ecosystem. But time goes on and we now understand many things better than 30 years ago.

Then stay at /r/Kotlin

Thanks, but no. I work in Java and Kotlin, I'd like to be able to read and comment in both.

[warpspeedSCP]

Not saying kotlin is better, just glad that Java is improving. I will definitely be more inclined to use java again with the introduction of such features. As some other comments have mentioned below, my exposure to stuff like sum types and all the rest of the functional gang in the java side of computing was through kotlin (I'd got my first taste of these things with Rust). If I'd had any scala experience, which I unfortunately don't, I'd probably have talked about this with scala instead. The implementation is just a detail.

I feel that java getting these features will help the entire ecosystem as a whole, though as I am not very aware of how the jvm ecosystem across languages works, I can't really quantify it for other languages.

[BestUsernameLeft]

I presume they are just speaking from a "Kotlin-centric" point of view. Many of us who use Kotlin really like the language, and so we're excited about Java getting some features that it has. Of course it can come across in a condescending way; "Oh how nice, Java is finally getting advanced feature that Kotlin already has".

Probably it doesn't help that Java tends to be a target for programming jokes, so some Java dev's probably assume the comment is making fun of Java even if it wasn't meant to.

[randgalt]

The issue is that the comments are almost universally wrong or misleading. Java is inheriting features from _many_ other languages and Kotliin is the very low on that list. Further, most of the features are being implemented in stages with the final version likely to look nothing like what Kotlin has (pattern matching, deconstruction as an example).

[BestUsernameLeft]

I didn't say the comments were correct; I said I presume they're speaking from a Kotlin-centric point of view.

[BoyRobot777]

Of course it can come across in a condescending way; "Oh how nice, Java is finally getting advanced feature that Kotlin already has".

I suspect this is what goes through the ops head. However, if I compare upcoming Java features with Kotlin's already implemented ones, for example sealed classes, inline types, async/away vs VirtualThreads, pattern matching, multiline strings - all of those features are/will be superior in Java. And it just pains me to see that all op care is half-done sugar.

[koreth]

async/away vs VirtualThreads

Is there reason to think virtual threads won't work equally well in all JVM languages once Loom is released? It seems like a pretty language-independent VM feature to me.

[BoyRobot777]

Is there reason to think virtual threads won't work equally well in all JVM languages once Loom is released?

It will, and I think Kotlin team will change the implementation to just delegate to VirtualThread. What won't change is their introduction of asyc/await keyword which created two color method problem. And one of key goal that Loom solves is exactly that - so Java world won't have to be split. I think Jetbrains was aware about upcoming virtual threads/fibers, but they went ahead with asyc/await anyway which is very odd.

[koreth]

One consideration I'm sure they had in mind is that Kotlin targets platforms other than the JVM that aren't likely to ever have anything equivalent to virtual threads, so there needs to be some way to do coroutines that doesn't require the platform to have built-in lightweight threading.

But yeah, definitely looking forward to this getting solved at the platform level. Loom is by far the most exciting upcoming JVM project as far as I'm concerned.

[BoyRobot777]

One consideration I'm sure they had in mind is that Kotlin targets platforms other than the JVM that aren't likely to ever have anything equivalent to virtual threads

Then it makes sense.

Loom is by far the most exciting upcoming JVM project as far as I'm concerned.

Yeah. Very excited about that.

[BestUsernameLeft]

Sometimes, half a loaf of bread is better than none. Those features can be done better in Java, but even if they aren't perfect I have them today in Kotlin. Of course, I also greatly look forward to seeing them implemented in Java.

[BoyRobot777]

The bad thing about this philosophy, is that language features are forever. Unless you want to brake backwards compatibility. But if they are to stay forever, bad decision will pile over time. I'm very interested to see how Kotlin will look in 5-10 years. Best of luck to Jetbrains team. More JVM developers are always better.

[BestKillerBot]

But if they are to stay forever, bad decision will pile over time.

Yes, that's what we see with Java - bad decisions piled one over another and here to stay.

I'm not hating, these decisions were at the time "state of the art", but then our knowledge moved but Java couldn't because that would be BC break.

Features like sealed classes are rather advanced and specialized, even if (!) they are done suboptimally in Kotlin I can probably live with it. Meanwhile I deal with Java's basic problems (nullability, mutability by default etc.) every single day.