[Reactor Gen4] The Rationale for a Generation 4 of Reactor about reactor

[simonbasle]

📢 Reactor 2022.0 to stay at Reactor 3 generation level

After much debate, prioritizing the topics we most want to see for the next 2022.0 train,
taking into account the feedback from our community and evaluating the risk/benefits of a new architecture / a new Java baseline,
we've finally reached a decision for the next version of Reactor.

The 2022.0 release train line will continue with the same Reactor 3 architecture and Java baseline.

What it means for Reactor-Core and Reactor-Netty

As such, Reactor-Core will continue the 3.x line with a 3.5.0.
Reactor-Netty will however split into two stacks: one for Netty 4, continuing the 1.x line with a 1.1.0, and one for Netty 5.
The later stack will likely be separate modules, with their own versioning.

To be perfectly clear: the Java baseline for the 2022.0 train will still be Java 8.
The only exception is Reactor-Netty for Netty5, which will require Java 17.

This release train line will focus on:

• offering a Netty 5 stack
• improving performance and internal RS optimizations
• integrating efforts around observability
• improving the user experience when mixing imperative and reactive code (particularly with thread locals)

Looking ahead, past Java 8

As we cannot stay on Java 8 forever, the team thinks there should be at least a tentative plan for upgrading.
We expect a discussion around Java baseline upgrade should occur again as we get closer to the next LTS, Java 21, in parallel to the present continuation of Reactor 3 generation.
This might be pushed a little if we foresee a subsequent Java version is likely to drive much more adoption than Java 21.

This gives our users and ecosystem outside of Spring an additional 2 years to plan around this Java upgrade.

For core, it would represent a 4.0.0.
Note that it might also be an opportunity for much deeper API and architectural changes, representing a new generation of Reactor, but that decision will come much later.

[bric3]

In terms of smaller scale change. I always thought that RxJava observable types described better the semantics of the stream.

• A Completable will either complete or error.
• A Maybe will either return something or not then complete, or error.
• A Single will either return something then complete, or error.

These types immediately describe the method, valid operations are limited by the time type system. While a Mono always requires some inspection to get the stream semantics, and eventually requires to apply defensive technics.

I understand this significantly expand the API surface, for integrators as well, yet I'd like to believe the safety of these types outweigh this cost.

[JonathanGiles]

Thank you for taking community feedback and making this choice. I know it would not have been an easy decision, or the 'fun' decision, but from a community support standpoint I believe you've absolutely made the best call. Thank you.