[Reactor Gen4] Discussing switching to a JDK 17 baseline about reactor

[OlegDokuka]

What about integration with project loom?

It is not in the topic since no one knows when Loom is released

[JonathanGiles]

Just to register myself as a data point - I am responsible for the Azure SDKs for Java, and we have gone heavily in behind Reactor as our public reactive implementation. This means we expose Flux, Mono, etc through our APIs. In some senses this represents our faith in Project Reactor to do the right thing, but it also burdens us as we ride the dual waves of remaining current with our customers (i.e. those using Spring releases that pull the reactor version forward) and maintaining API compatibility (and working implementations!) by not moving too eagerly to new versions. This is a difficult position to be in, and the frequency of breaking changes in Reactor does prove to be troublesome.

It is a shame that there isn't a better reactive abstraction story in Java. I wish this could be reconciled. I don't think that the JDK 9 Flow or the reactive streams APIs are the right abstraction either. But I would love to see our support continue for Reactor, without the need to expose it through our public APIs (and rather to expose a common interface that could be implemented appropriately).

In terms of this Reactor 4.x proposal, my feedback is similar. I know in the Azure SDK for Java team, we are excited by opportunities to use features beyond our current JDK 8 baseline, but market realities dictate that we can't yet (although we get by in some cases with multi-release jars to use some of the new features). I can't foresee us dropping JDK 8 as a baseline for quite some time yet, which means we are unlikely to move to Reactor 4 in any great rush. I therefore anticipate the situation where users will be forced to bring in Reactor 3 and 4 in the same application, so we need to be sure that good side-by-side support is enabled.

[jorsol]

Since Flow was never adopted even within the JDK, and since the whole reactive ecosystem is still on Reactive Streams interfaces, we see no benefit in pushing for a switch.

It's used in the Java 11 HttpClient.

We also discussed the Reactive Streams dependency for Spring Framework 6 a while ago, with the same conclusion: java.util.concurrent.Flow has not seen any adoption, so org.reactivestreams remains the canonical version to use.

It has not seen any adoption because is not used, when an important framework starts to use it, then it will get more traction.

FWIW, R2DBC plans to remain using Reactive Streams. There are no plans to use JDK9 java.util.concurrent.Flow as R2DBC uses Java 8 as baseline. We do not want to change the baseline for R2DBC 1.0.

Ok, the problem I see is not the adoption, but compatibility, since the ecosystem still uses Java 8 as the baseline, is a bit disappointing because we won't see any adoption of Flow since it's not used, and is not used because the ecosystem doesn't change the baseline, and even then org.reactivestreams will be used for interoperability reasons so we are back to the start.

Well, the Reactive Streams website will not hold true ;)

This means that there will be a migratory period, while libraries move to adopt the new types in the JDK, however this period is expected to be short...

Anyway, it's not a big deal since they are essentially a bunch of interfaces and the org.reactivestreams has a FlowAdapter, yet I still think that adopt the new types should be great.

[ingenthr]

Seems like there are at least 3 projects that will need a Java 8 solution for some time then:

• Couchbase (who may consider having two versions with different Reactor/JDK support)
• R2DBC (who are sticking with Java 8 until 1.0)
• Azure SDKs for Java (who would probably have to stick to Reactor 3, and would hope for side-by-side Reactor 4 support)

Is that a fair summary?

[JonathanGiles]

@JonathanGiles Is your recommendation Reactor Netty to stay on Netty 4? Because Netty 5 development is already on top of Java 11 and comes with a pretty new ByteBuf API. This decision is important because it will affect also Spring Framework 6 and the Netty runtime that is supports.

@violetagg I don't actually have a good recommendation at the moment - I'm just registering myself as a data point. I appreciate the opportunity to discuss the topic as I think it can have far reaching implications and it is sometimes easy to not fully appreciate the impact of our decisions.

I'm not sure if, from the perspective of reactor and reactor netty, there is a better alternative than to run side by side releases, but I will need to give it more consideration. This would then force my team to run side by side releases also, which is a bit early in our lifecycle to already introduce major breaking changes, but it is the likely outcome. My team is meeting this week to work through our options and so we will have more thoughts to share soon.

[martin-g]

I understand what you say! We all have our users.
But if you (i.e. your company) does not start communicating now that your product will require Java version X in Y years then probably some of these clients will never upgrade.
Giving your users few years heads-up and then few more years support for the old/current version is more than enough.

[mp911de]

• changing the Flux API to reduce the number of top-level operators by grouping the ones with most variants (or the ones that are too advanced) under sub-api groups

Having deprecations now in place would be beneficial to know which operators are going to be affected. On the other side, a deprecation without a replacement is a bit counterintuitive.

• make use of Java 9-17 features like sealed classes and records

While I understand it's desirable from a maintenance perspective, users of Reactor 4 will be required to elevate their baseline to Java 17 regardless of whether the library actively seeks a baseline upgrade or is just fine with remaining on Java 8.

Several Java libraries (especially drivers) can remain up today with Java 6 compatibility to provide connectivity options for newer database versions while not requiring a Java baseline upgrade to support a wide range of applications. Clearly, most of these have arrived at Java 8 as baseline. Upgrading the codebase and build infrastructure to Java 17 can require a significant amount of work. With the current support models for Java 8, we should expect Java 8 to remain widely used throughout the next years.

What do you think about a Reactor 3.5 version co-released with Reactor 4? 3.5 would contain all the desired API changes from version 4 (additional operators, deprecations) while 4.0 is the modern target that can be used once consumers of Reactor are actually ready to do the switch?

Coupling API changes to infrastructure changes creates tension to some degree.

[jorsol]

Moving the ecosystem from Java 8 is always good, and target Java 17 as the baseline is even better! So +1

I haven't read any mention of this but, Reactor 4.x will drop the org.reactivestreams dependency and make use of JDK9 java.util.concurrent.Flow? There is no need for org.reactivestreams anymore.

[simonbasle]

otherwise I would like to see what's actually going to be conflicting

@smaldini I think we would need a repackaging anyway just for the purpose of allowing Reactor 3 running alongside Reactor 4 (as demonstrated by some comments here, it's likely some libraries won't make the jump quite yet to Reactor 4). I also wonder if we need to anticipate a Reactor 5 already. But your remark on Flow could make sense.

Apparently the JUnit team had the same questions for JUnit 5 / Jupiter and they decided to use a codename in the package structure rather than a direct reference to the major version (and despite pushback from some users, they think today this was the best course of action).

Trouble is, we have codenames for release trains so what should the package name be? 😆

[akarnokd]

Any operator that allows the user to produce multiple values for each invocation needs to be backpressure aware. For example, a traditionally unbounded Flux.create would have to utilize blocking on a virtual thread when running out of downstream requests. By itself, using subscribeOn with a virtualized scheduler would not work. Thus, you'd need a separate, virtual thread-requiring implementation integrated into such an operator.

Can't comment on the stacktraces yet. You may get shorter ones, but a million of them.

[mp911de]

I have the feeling that Reactor Netty should follow Netty 5 and raise the baseline to at least Java 11 in alignment with Netty. Netty 4 isn't going to go away immediately and integrations will require a while until they get there. An application using Spring 6 with Netty 5 isn't going to work with Lettuce or the Cassandra driver as both are based on Netty 4.

It looks as if Netty-based libraries will have to follow an all-or-nothing migration path.

[JonathanGiles]

From my internal team discussion today, the main requests I would have for Reactor include:

• Ensuring that reactor v3 and v4 can be used side-by-side in a single application (e.g. different package names at least).
• Minimise API breaks in the v3 branch as much as possible (ideally, entirely!).
• Plan to reduce breaking API changes in the v4 branch to the bare minimum (the current frequency of deprecations and breaking does prove burdensome downstream).
• Investigate and build adapters to adapt between v3 and v4 Reactor APIs.
• (This one is very hand wavy, but bear with me) Investigate the possibility of Spring framework support for transparent v3 <--> v4 Reactor API conversion, so users do not have to litter their code with calls to adapters as in the last bullet point.

Thanks!

[simonbasle]

I'll keep this issue focused on JDK 17. @msgilligan interesting feedback. I've opened a sister issue for the repackaging: #704

[vmptk]

What about integration with Project Loom?

[daschl]

This ticket got raised partially because I was speaking to @simonbasle about it from the Couchbase Java SDK perspective which depends on Reactor 3. If Spring Boot 3 / Spring 6 will required JDK 17 and Reactor 4 will do the same, there will be a split of the ecosystem which might be fine if you live inside the spring world (since spring boot 2 will be maintained for some time).

But for library authors like us it will likely mean having to do another major release depending on Reactor 4 and then maintaining two major releases for a looong time since as we know the ecosystem moves very slowly (right now our baseline is java 8).

Having some form of interoperability and/or migration story will help us and others to make the transition period smoother for users.

[martin-g]

@daschl What is the reason to stay with JDK 1.8 ?
When Java 9 has been released many developers were afraid to upgrade because it wasn't LTS and because many of us didn't know how JPMS will break our apps/libraries/frameworks.
When Java 11 went out many shops preferred to stay with Java 8 for some more.
Since then Java 12, 13, 14, 15 and 16 were released and IMO they were pretty high quality!
IMO it is time to push our users and dependents to start upgrading their Java!

[daschl]

@martin-g this is not only a technological but also a business decision. Of course personally I'd love to jump on 17 immediately and use all the cool features, but as a database provider we can't dictate on which platforms our customers run on. The reality is that many enterprises run on Java 8 or 11 and that will not change for the foreseeable future, so it's something we have to accept and work with as best as we can. We can certainly provide guidance and best practices, but not "push" them.

Edit: I should add that I understand where spring is coming from, and there is a reason why boot will be maintained in the current major version for some time. If you live in the spring ecosystem most of these things will be done for you, I think reactor has a special place because it is also used outside of the spring world.

[daschl]

I understand what you say! We all have our users.
But if you (i.e. your company) does not start communicating now that your product will require Java version X in Y years then probably some of these clients will never upgrade.

Of course we'll do that, but that is orthogonal and actually off-topic/unrelated to the core of the issue.

Giving your users few years heads-up and then few more years support for the old/current version is more than enough.

That might be your opinion - every company has its own set of support and EOL policies which we don't need to discuss here since there are so many of them. And it's unrelated to the technical nature of the issue described so if you want to chat more about this we should bring into a different forum I think so we don't derail the technical focus.

[simonbasle]

What do you think about a Reactor 3.5 version co-released with Reactor 4? 3.5 would contain all the desired API changes from version 4 (additional operators, deprecations) while 4.0 is the modern target that can be used once consumers of Reactor are actually ready to do the switch?

That's certainly an option, we've thought about it. When would the deprecated APIs be removed though?

From your comment, sounds like 4.1.0 would be the least disruptive, but that kind of reduces the benefit of that particular change 🤔

[mp911de]

With 4.0. 3.5 would introduce deprecations and replacements and 4.0, the co-released one would ship with the deprecated API being removed.

[violetagg]

I would like to mention that we want to upgrade eventually to Netty 5 which will come with a new ByteBuf API ...

[violetagg]

With 4.0. 3.5 would introduce deprecations and replacements and 4.0, the co-released one would ship with the deprecated API being removed.

Also how this is related to the new Spring Framework/Boot and which version will they use? Or the drivers will package the version that they want to use and thus will be independent from the frameworks?

[simonbasle]

Also how this is related to the new Spring Framework/Boot and which version will they use?

This would basically align with Spring 6 / Spring Boot 3.
The same rationale and caveats apply to us as the ones exposed by Juergen Hoeller here: https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6

[akarnokd]

I don't quite see why jump beyond Java 9 at the moment. Records have immutable fields so not sure where internally they would go or do. Sealed classes limit implementors but you could probably hide them in internal packages and via the package system. var, switch, multiline strings: mostly sugar.

Loom won't be in 17 for sure. Supporting Loom means having scheduler workers backed by virtual threaded executor so user code can freely suspend in the callbacks. However, since many blocking APIs use checked exceptions, j.u.f.Function et all may become quite inconvenient. Also rewriting the lock-free backpressure management would require locks to block on (or a delicate dance with park()-unpark()) so it is doubtful the code will look or perform better.

Valhalla (value types & generics) is also out there in the future and by itself would require some restructuring around the internal queues at minimum.

[simonbasle]

I don't quite see why jump beyond Java 9 at the moment

Netty 5 is shaping up to have a baseline of Java 11, so that would be a minimum anyway. If we're talking about Reactor 4 end of next year, Java 11 will already be going towards its sunset.

Making the hard jump to the latest LTS version of Java has (arguably smallish for core) benefits in the language. AND it's an opportunity to a forward-looking basis for the years to come, with Java 17 to 23 at least, or even 29 actually...

of course, Reactor 3 would continue to be maintained for an extended period for people that want to stick with Java 8....

[simonbasle]

Valhalla (value types & generics) is also out there in the future and by itself would require some restructuring around the internal queues at minimum.

so in your opinion that might be a bigger driver for changing the baseline, but at a later time? I thought about that, and ScopeLocal that (might?) come along Loom, but as stated above Netty 5 is a stronger driving force for a Java bump sooner rather than later, so at that point 17 becomes a better choice over 11 anyways.

[akarnokd]

so in your opinion that might be a bigger driver for changing the baseline, but at a later time?

I'm pretty sure you can compile Reactor to target 11+ already without changing a single line of code. I don't think there are any standard Java construct beyond 9 up until Loom/Valhalla that would require any direct support from the perspective of the users of the library. (Historical example: jumping from Java 6 to Java 8 and adding first class support for Stream.)

Loom is still a wildcard for now.

[simonbasle]

I haven't read any mention of this but, Reactor 4.x will drop the org.reactivestreams dependency and make use of JDK9 java.util.concurrent.Flow? There is no need for org.reactivestreams anymore.

That is a good question. The main benefit of these interfaces on a day to day basis are the interoperability they provide. Since Flow was never adopted even within the JDK, and since the whole reactive ecosystem is still on Reactive Streams interfaces, we see no benefit in pushing for a switch. Other actors in the space agreed to that when it was discussed in a Reactive Foundation meeting.

This is very important if we want to continue efficiently interoperate with eg. RxJava2 and RxJava3.

Furthermore, staying on Reactive Streams would ensure Reactor 4 can be very easily interoperate with the Reactor 3 classes as well.

[mp911de]

FWIW, R2DBC plans to remain using Reactive Streams. There are no plans to use JDK9 java.util.concurrent.Flow as R2DBC uses Java 8 as baseline. We do not want to change the baseline for R2DBC 1.0.

Going forward, a lot of other specifications (e.g. Microprofile) are based on Reactive Streams. Switching to Flow would require always glue code, and that increases code complexity significantly for interop-arrangements.

[jhoeller]

We also discussed the Reactive Streams dependency for Spring Framework 6 a while ago, with the same conclusion: java.util.concurrent.Flow has not seen any adoption, so org.reactivestreams remains the canonical version to use.

For the inclined, we provide adapters for java.util.concurrent.Flow already, but for the ecosystem overall and in particular for binary integration among pre-compiled components it is a non-topic for the foreseeable future.

[jhoeller]

Since it hasn't been mentioned here yet, as mentioned in a chat with Simon yesterday, I'm strongly in favor of a regular package name such as io.projectreactor with no version baked in, leaving the option to reuse the same package for Reactor 5 as well. Otherwise we might end up with an OkHttp like situation where they do a 4.0 release with okhttp3 packages for backwards compatibility... If necessary, the package name can still be version-qualified for Reactor 5 later on.

[smaldini]

@jhoeller I like the idea of progressing to a new package name if needs be, e.g. implementing Flow.Publisher instead of RS but otherwise I would like to see what's actually going to be conflicting. Is Spring 6 going to offer partial support for Loom if it gets a preview API in Java 18 or Java 19 ?

@akarnokd do you think Loom would affect some operators internals as well ? For instance using a virtual thread per user publisher or specific async operator to reduce the stack trace in the guarded drain loops using "blocking" wait ?

[vipcxj]

I released a apt library JAsync recently. It implements Async-Await pattern just like es in Java. And it use Reactor as its low level implementation. It is in alpha stage now. With it we can write code like that:

@RestController
@RequestMapping("/employees")
public class MyRestController {
    @Inject
    private EmployeeRepository employeeRepository;
    @Inject
    private SalaryRepository salaryRepository;

    // The standard JAsync async method must be annotated with the Async annotation, and return a JPromise object.
    @Async()
    private JPromise<Double> _getEmployeeTotalSalaryByDepartment(String department) {
        double money = 0.0;
        // A Mono object can be transformed to the JPromise object. So we get a Mono object first.
        Mono<List<Employee>> empsMono = employeeRepository.findEmployeeByDepartment(department);
        // Transformed the Mono object to the JPromise object.
        JPromise<List<Employee>> empsPromise = JAsync.from(empsMono);
        // Use await just like es and c# to get the value of the JPromise without blocking the current thread.
        for (Employee employee : empsPromise.await()) {
            // The method findSalaryByEmployee also return a Mono object. We transform it to the JPromise just like above. And then await to get the result.
            Salary salary = JAsync.from(salaryRepository.findSalaryByEmployee(employee.id)).await();
            money += salary.total;
        }
        // The async method must return a JPromise object, so we use just method to wrap the result to a JPromise.
        return JAsync.just(money);
    }

    // This is a normal webflux method.
    @GetMapping("/{department}/salary")
    public Mono<Double> getEmployeeTotalSalaryByDepartment(@PathVariable String department) { 
        // Use unwrap method to transform the JPromise object back to the Mono object.
        return _getEmployeeTotalSalaryByDepartment(department).unwrap(Mono.class);
    }
}

So far, only Mone to JPromise transformations are supported and I am ready to introduce Flux to JFlux transformations in the future, making the following code possible：

JFlux<String> flux = JAsync.fromFlux(Flux.just("a", "b", "c"))
for (String v : flux.await()) {
    Mono<String> hello = Mono.just("hello").delayElement(Duration.ofSeconds(1));
    System.out.println(JAsync.from(hello).await());
}

And println will support concurrency.

[jhoeller]

It is a fine strategy for R2DBC and datastore drivers to remain on a Java 8 baseline for the foreseeable future, even several years down the line. From a Spring perspective, the same such infrastructure components should be usable in Spring Framework 5 as well as 6 applications, without the burden of double maintenance branches. Generally speaking, the main impact of the Spring Framework 6 baseline should be up the stack in the Spring portfolio, not down in infrastructure components.

The org.reactivestreams namespace is an ideal common ground for the time being. Frankly, it was more or less a mistake for Lightbend to assume that the JDK 9 Flow variant would be a quick replacement in the open source ecosystem. Instead, it's probably best to see Flow as a Reactive Streams equivalent for use in other JDK APIs such as the HttpClient where they can't have external dependencies... with us adapting to it where needed but not basing our own APIs on top of it.

So from my perspective, I'm certainly not advocating for a full split of the ecosystem, quite on the contrary. It's highly desirable to provide as much interoperability as possible, with a high degree of reuse of existing components across the generations. Now, the key question is how Reactor can contribute to that goal, while also being able to modernize itself at the API level as well as in its internals. Maybe it's indeed best for the ecosystem to remain on Reactor 3.x for the time being, with Reactor 4.x taking time to reinvent itself - and going out of its way to integrate with Reactor 3 based Reactive Streams infrastructure side by side?

[simonbasle]

one important thing that I failed to take into account: Netty 5 will likely not be runnable on the same classpath as Netty 4 (especially with native implementations).

Since all three projects identified so far that will need continued Java 8 support are based on Netty via Reactor-Netty, it appears that dual-run idea isn't that clear-cut as I initially thought...

So instead we'd just extend the Java 8 support and the Reactor 3 generation with a 3.5.x along 4.x...

Libraries that can't fully commit to the JDK jump have several choices:

• maintain two dedicated lines as well (best compatibility with the Spring ecosytem)
• maintain two lines but one is just shading Reactor-Netty and Netty 4 in it (least effort for MVP integration in Spring 6)
• maintain a single line based on Java 8 only (not really compatible with integrating in Spring 6)

[JonathanGiles]

For the Azure SDK for Java, we support a pluggable HTTP client structure. It is conceivable that in a future where we baseline on JDK 17, that we would baseline on the HttpClient in the JDK (assuming we can get good performance through native SSL integration). We would continue to support Netty, and presumably we would ship separate plugins for Netty 4 and Netty 5. This would be done in the name of reducing our dependency count, which is something we try to do as much as possible.

In the meanwhile though we would likely continue to baseline on JDK 8 with Netty 4 and Reactor 3. When it comes time for us to move forward to a higher baseline, it is likely we will have to do a major version release of our libraries and maintain two separate lines for quite some time.

I don't think the shading option works for us. We cannot shade Reactor APIs from our public API scope - this would not be a satisfactory outcome for users - so any shading of reactor-netty and Netty 4 doesn't seem to really result in any particular wins from my perspective.

My concern remains this: when the next releases of Spring / Reactor come out with a JDK 17 baseline, these frameworks are in the fortunate position of being both at the bottom of the stack and the critical mass. Libraries that are used on top of this are caught in a battle between supporting eager Spring / Reactor upgraders, and our long-time users who need stability.

I am actually far less concerned about Spring moving to a JDK 17 baseline. We can live on top of that without issue (we know we work on JDK 17). I am far, far more concerned about Reactor moving to JDK 17 baseline, because that drags us with it, or more realistically, leaves us on the 3.x branch. I would echo @jhoeller comment about moving slowly, as much as possible. I think it would be really useful to enumerate the reasons for wanting to baseline on JDK 17, and which of those are seriously valuable vs 'nice to have'.

[violetagg]

@JonathanGiles Is your recommendation Reactor Netty to stay on Netty 4? Because Netty 5 development is already on top of Java 11 and comes with a pretty new ByteBuf API. This decision is important because it will affect also Spring Framework 6 and the Netty runtime that is supports.

[simonbasle]

Discussions in this issue so far have focused a bit on JDK 17, but there are other incentives for a gen 4. We can split the discussion along more axis, in which case I'll link to an epic-style tracker issue.

A second big driver for a gen 4 (but not necessarily for a JDK bump) is the goal of removing the implicitness of prefetch. This is breaking expectations and changing the defaults, so we think it can only happen in a major version. I'll need to get into more details in a separate comment or issue...

A gen 4 would also allow us to sanitize the plumbing and open it up for broad enhancements. Ultimately, most of these changes will benefit users, but they'd be in the background rather than huge direct selling points to them.

Here is a short list:

• Netty 5 support (implies at least JDK 11, but at that point we'd move to 17)
• More explicit about backpressure / prefetch (no-prefetch first)
• Better user experience (API groups, debugging and tooling?, better introspect ability…)
• Better performance (varHandles, state machines)
• Better maintainability ? (state machines, context, cancel ack…)

[simonbasle]

FYI it looks like Netty 5 will ultimately be runnable alongside Netty 4. At least, they've planned on changing the package and groupId: https://groups.google.com/g/netty/c/uT0Ay7j_Ey0?pli=1

This opens up the possibility of supporting Reactor-Netty 1.x and 2.x in the same codebase, again bringing up the question of repackaging for reactor gen 4 as a whole.

[msgilligan]

Which means changing the root package and package structure, to something like io.projectreactor.reactor4 maybe?

Please don't end the package (module) name with a number -- especially if you're going to do "modularity proper" (which I'd love to see happen) -- because it will result in warnings during the build.

I don't have a great suggestion, but maybe ng or iv or something similar might work?

[simonbasle]

Reactor will keep on Java 8 for the foreseeable future, using 3.5 as the foundation for Spring 6.0. See announcement in issue #705