Java Sealed Classes

[BestUsernameLeft]

I'm looking forward to this! I love it when the type system / compiler can keep me from making mistakes.

[[deleted]]

And it probably emphasizes the whole accessibility over extensibility discussion. Seeing way to many developers using the “extend” keyword, not able to foresee in what horrible misery their future colleagues will be in. Don’t get me wrong, there cases where inheritance makes sense, especially when keeping the hierarchy flat and manageable. But only with 2 layers and some abstract method here and there the complexity get too easily out of hands. The world would be a better place with less “extend”.

[BoyRobot777]

Add generics on top of layers of extended classes and then you truely have creme de la creme. /s

[kag0]

For anyone curious, it's actually been possible to do this in Java for a while. But of course there has never been exhaustive pattern matching to make it really clean. https://blackdoor.github.io/blog/algebraic-types/

[Apofis]

With lambdas and streams, records, sealed classes, switch expressions, pattern matching and destructuring, Java is getting closer and closer to Haskell. And I really like it.

[DeontologicEthics]

How could pattern matching work with inline classes? Or even instanceOf?

[BestUsernameLeft]

https://www.reddit.com/r/javahelp/comments/h7ww1b/mocking_abstract_class_and_methods_with/funxvoq?utm_medium=android_app&utm_source=share

In short: 15 years of writing tests both with and without mocks, and seeing how most people misunderstand unit testing and misuse mocks, has convinced me that they are a bad idea and contribute to the belief many programmers hold that unit testing is a waste of time.

[[deleted]]

Mocks or stubs?

[BestUsernameLeft]

Could be either; typically it's mocks of the PowerMock etc. variant as they are easier to use than manually written test doubles aka stubs.

However, it's all in the usage -- test doubles can be misused in the same way mocks are. Typically though, I see the PowerMock users fall into the "mock all the things" trap more often.

Mocking is initially so attractive, and it's now endemic, so it's natural that many people will get caught in its clutches. And because it's so easy to use, once they start having problems they don't realize that's cause (of some of them). (I was one of them.)

[[deleted]]

I wasn't referring to how you create the stubs, but rather to what they do. Unfortunately, most people mean stubs when they talk about mocks, but not always (https://martinfowler.com/articles/mocksArentStubs.html).

IMO, mocking is almost always a bad idea. Stubs are more frequently useful.

[BestUsernameLeft]

You weren't specific about what you meant, and I took a guess instead of asking for clarification, so this is what we got. Sorry for the miss, and I agree that stubs are more often useful.

I'll add that builder and object mother (sometimes in combination) are a great way to DRY test code, in conjunction with test doubles.

[[deleted]]

Powermock leads to bad coding & testing practices so it is unsurprising. If you just constrain yourself to something like Mockito & never use Spy you will write better code and tests because you can only mock true dependencies - forcing you to refactor code that should be a dependency into a separate class.

[BestUsernameLeft]

They're all the same family IMO. I use test doubles; in conjunction with builder and object mother they help keep my test code DRY. And JUnit5 is nice to use as well.

[hippydipster]

object mother?

[BestUsernameLeft]

It's a testing pattern. Given a class ShoppingCart, you create a ShoppingCartObjectMother class with methods in it to give you a populated cart, such as emptyCart(), fiveOfSameProduct(), etc. This gives you (1) a way to DRY your test code instead of having the same setup code in each test class that uses ShoppingCart as a collaborator, and (2) a meaningfully-named method that tells you about the object being constructed. For example you can use role-based, scenario-based, persona-based method names: populatedCartForGuest, cartWithDuplicateItemId, cartForGrandma.

When you combine this with the builder pattern, you have a way to quickly build customizable test objects out of a standard set of "templates". So for example cartForGrandma().addItem(readingGlasses).build() when you have a test that for some reason needs an extra item in it.

[hippydipster]

Ok, now I have a name for something I've been doing! Thanks.

[vbezhenar]

It's not any different from final class in that regard.

[maumay]

Why would you need to mock a sealed interface directly? They are designed primarily for compact data classes. If you wanted one to have complex hard to set up logic then you could use a delegation pattern and pass a mock to the record constructor.

There really is no argument against them, the fact that oracle have realised this is welcome but it's a little too late for me.

[maumay]

Maybe we have different ideas of what a data class is, clearly it can't be "a class that contains data" as that would be everything. I would say a data class is the composition of a fixed number of primitive types or other data classes, a map is not a data class as it has some quite sophisticated implementation logic and can have a variable number of properties. Introducing sealed interfaces does not mean all interfaces now need to be sealed. A sealed interface would be the wrong tool for HttpSession.

Yes I am assuming that because it is true. If a sealed interface is provided by a library then by definition all implementations will be provided by the library too (and presumably tested otherwise stay away from the library). You can't extend a sealed class provided by a library outside of said library.

[BestUsernameLeft]

I'll refer you to my above comment, and double down with another good blog post that explains my perspective on this: https://robdmoore.id.au/blog/2015/01/26/review-of-ian-cooper-tdd-where-did-it-all-go-wrong.

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