Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support JDK9 Flow.Publisher as an adaptable reactive type [SPR-16052] #20601

Closed
spring-issuemaster opened this issue Oct 6, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Oct 6, 2017

Brian Clozel opened SPR-16052 and commented

Currently the ReactiveAdapterRegistry supports Reactor, RxJava, all Publisher types, etc.

This issue is about adding an adapter for JDK9 Flow.Publisher - an example of that can be found in Reactor.


Affects: 5.0 GA

1 votes, 6 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 6, 2017

Sébastien Deleuze commented

Reminder: documentation should be updated as well to mention such support.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 13, 2017

Juergen Hoeller commented

Can we possibly call that Reactor JdkFlowAdapter directly there, not duplicating the actual adapter code on our end? That would also avoid the compilation problem for us, that is, which variant of java.util.concurrent.Flow to build against (JDK 9 or backport).

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 13, 2017

Rossen Stoyanchev commented

I think we would need to bring in the backport jar (available in libs-milestone) with a custom configuration like Reactor does it. Without that we can't call JdkFlowAdapter.flowPublisherToFlux and JdkFlowAdapter.publisherToFlowPublisher.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 13, 2017

Juergen Hoeller commented

Could we call it via reflection? Even if we could, there's probably no need to... No worries from my side using such a jar for plain compilation purposes, not exposing it in any POMs of ours. And once we have a build requiring JDK 9+ (like they plan it for JUnit 5.1), just producing JDK 8 compatible binaries, the problem goes away in any case. We might have a need for such a build in the Spring Framework 5.1 timeframe already, optionally calling new JDK 18.3 APIs in a few places.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 16, 2017

Rossen Stoyanchev commented

Now that the reactive-streams-jvm project includes an Flow bridge, we might as well wait for that to be "back released" as version 1.0.1. I am not aware of any library producing a Flow.Publisher yet so I think we would be okay to fix for 5.0.2 if we don't make 5.0.1. For the time being, until we we have a build that requires JDK 9+, we can use reflection as a temporary solution.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 17, 2017

Rossen Stoyanchev commented

On second thought, I've added support for Flow.Publisher based on the adapter from Reactor. The advantage is that reactor-core is most likely on the classpath and that could be more convenient vs requiring the extra reactive-streams-flow-bridge dependency. The Flow bridge from reactive-streams-jvm could be useful in cases where reactor-core is not present on the classpath, which could be the case with Spring Data. Once the Flow bridge is released we can add that as a fallback alternative.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.