On: Java 21: First Release Candidate

[clumsysmurf]

> Reactive java should be avoided (IMO). It was a decent choice for old java, for virtual thread java you get little benefits from it.

This is interesting, we used RxJava quite a bit on Android until Kotlin Coroutines made things a bit easier in that the code read more linearly and worked nicely with built in language features like exceptions for error handling.

Just curious if you agree with this in Java, or had other reasons.

[vips7L → clumsysmurf]

Even before the introduction of virtual threads RxJava should have been avoided.

It colors your entire code base, prevents natural error handling, and quite frankly makes maintenance that much more complex.

Obviously there’s a place for it, but every project I’ve been on that used it shouldn’t have.

[Alupis → vips7L]

I'm curious about this from the perspective of a functional Kotlin backend (using Arrow or not).

Do virtual threads make reactive within that model unnecessary too? Seems maybe not? Reactive is both a model, and a paradigm, no?

Even with virtual threads, there will still be a reason to write reactive programs it seems.

[prpl → Alupis]

I think it's (looesely) tasks vs threads. Threads have a stack trace and a well defined state in the JVM, tasks are objects on the heap.

I work on moderate sized async reactive pipeline with lots of CompletableFutures throughout (and chaining of them so you can process a batch in parallel and commit contiguous offsets periodically) and there's several bugs that have been undebuggable because they happpen _infrequently enough_ in prod, the heap dump is huge, and there's no stack trace to tell you what is going on. The best you can do is lots lots and lots of logging and turn it into an analytics problem to find out what happened (to be fair, logging is only marginally better than wading through a heap dump of completable futures).

[cogman10 → prpl]

There's going to be a difference in the way you do things. Most of the completable future API is going to be unnecessary, .join will work better as there's not penalty for blocking.

I've made my fair share of completable future messes with a lot of biconsume/thenApply/handle nonsense to try and avoid blocking.

[cogman10 → clumsysmurf]

The reason to prefer kotlin coroutines is exactly the reason to ditch reactive for virtual threads.

The only difference is virtual threads have platform support which means even better stack traces and no need to decorate your method.

So yup, agree.

[netheril96 → clumsysmurf]

It will be years when most Android users are on Java 21. It’s also not a feature that can be transpiled. So for Android developers virtual threads are probably not a thing we need to understand or use in any near future.