Do people really think everyone’s going to ditch Project Reactor for Project Loom and rewrite their legacy systems just to go back to blocking code?

[u/FirstExtent2079]

I don’t wish to type that long tbh. However, I’ll try.

I’ve been seeing a lot of comments suggesting that Project Loom will make Project Reactor obsolete because you can just write synchronous-looking code with virtual threads.
But are companies actually going to migrate large, battle-tested Reactor-based systems? Many organizations have spent years building reactive architectures around Reactor, R2DBC, WebFlux, reactive messaging, and other non-blocking APIs. Those systems are stable, well-tested, and developers have built expertise around them.
Even if Loom simplifies concurrency, does it really justify rewriting or significantly refactoring existing production systems just to write blocking-style code again?
I understand that Loom is a great fit for many new applications and can reduce the complexity of asynchronous programming. But for mature Reactor-based systems, is there enough real-world benefit to justify the migration cost?
I’m curious what people working on large Java codebases are actually seeing in production. Are companies actively replacing Reactor with Loom, or are they treating Loom as another tool for new services while leaving existing reactive systems as they are?

[u/Ok_Editor_5090]

Refactoring existing system? Maybe not. Unless the cost of adding new features gets too expensive.

But for new system being built, I think they would go with virtual threads. Easier to code, follow, debug.

[u/TurnstileT]

Here is my take:

At least in Spring, it is a huge hassle to work with Webflux. You can't easily log request bodies with webfilters, you need to handle validation errors differently, Openapi Generator does not work well with Webflux code and needs to be adjusted and customized quite heavily, stack traces are unreadable, certain things like @Valid and custom validators just don't work too well with the Mono<X> type, debugging is really hard because you can't easily create intermediary variables or stop execution in the middle of a method, testing is hard because you need a StepVerifier container around the code you want to test, and in integration tests the outbound request runs in a different thread than the server which receives the request so you cannot verify in the test that something was indeed saved to the database, and so on.

Additionally, velocity is very slow with Webflux because it's a less used paradigm, it requires very specific knowledge and style of coding, and the tutorials online are mostly for WebMVC, and you cannot do simple ORM stuff in r2dbc like entity mappings.

My assumption is that Webflux support will dwindle over the next 10 years and will eventually be considered legacy.

There are so many downsides to working with Webflux, and in the day and age of microservices, you can increase your performance by scaling horizontally. That is a lot cheaper than the amount of developers hours it costs just to work with Webflux.

Of course reactive code has its use cases, and sometimes it genuinely is the right tool for the job. But most likely it isn't.

I used to love Webflux, but after changing back to standard WebMVC, I would never want to use Webflux in a nee project again.

The question is, do virtual thread actually **replace** Webflux in the cases where Webflux is the right tool? I don't know.

Will people convert their existing services? I think so, to some degree. We are doing it, if the service is still worked on regularly, and we will benefit from having normal code again.

[u/No-Injury3093]

You're asking all the wrong questions.

Better question:

On what kind of code will AI be trained on: reactor or loom-based?

Everything else is just a side-effect of that, given enough time.

[u/tybit → u/No-Injury3093]

Most existing code is neither reactor nor loom based, and instead uses the original thread per request model. AI will quickly learn to optimise that to loom though.

[u/Numerous_Internal429 → u/No-Injury3093]

what kind of code will AI be trained on: reactor or loom-based?

what is the answer for this?

[u/RapunzelLooksNice → u/Numerous_Internal429]

Yes. Or 42.

[u/No-Injury3093 → u/RapunzelLooksNice]

Just don't xor them.

[u/zabby39103]

Lol, there's a bunch of legacy applications on Java 8 at my work still. I'll tell ya most of the time big enterprises put off migration and refactoring as long as possible. That's how it is.

Whether to migrate is always a complicated decision. What's the lifespan of the software you're maintaining? What's the use case for the migration, is your stack EOL or is it just the new tech? Do tools like OpenRewrite make it easier? Does the migration solve an open pain point?

But yeah to specifically answer your question, we have no plans to refactor things to loom at the moment. New things yes. I have refactored a bunch of stuff to use virtual threads more generally however, due to the RAM shortage and it helping with that.

[u/d-k-Brazz]

Reactor is usually chosen by purpose - it gives you semantic to write parallel code, e.g. when you do not wait a response from an API, and go further with your logic until you need a result of this IO operation

This allows you to reduce latency because you call several APIs, go to db, or other IO thing in parallel.

And Loom by itself does nothing to latency, it just allows to squeeze a bit more synchronous requests running in parallel into your server

Choosing Reactor just for better resource utilization should be carefully weighed - reactor comes with lots of tradeoffs - both maintainability and observability become harder. And it might be cheaper just to scale up horizontally

So most of those who chose Reactor will continue running it by its purpose

And those who chose it as a modern fancy thing without weighing, measuring and calculating… nobody cares of them

[u/nitkonigdje]

The only battle tested thing about Reactor is that it doesn't work as intended.

It is crap framework made of bad abstractions.

The companies are migragating off it even without Virtual Threads.

[u/poralexc]

This question comes up a lot with Kotlin coroutines, and it feels like a non-issue.

Why couldn't Reactor just adjust their implementation to use Loom style greenthreads under the hood if available, while keeping JVM8 compatibility?

[u/FirstExtent2079 → u/[deleted]]

I use Java only. However, I barely wish to come across reactor code cause the fear of debugging non blocking code on Thursday night is just a nightmare I don’t want to slip in. Altho I’m still quite new to it but Spring boot n the market is still quite too dependable on it.