Hi Mark,
thanks for your input!
I know that Publisher and Subscribers are very specifically defined
contracts and we don't plan to change them in any way.
But..
JAX-RS 2.1 needs to be runnable on Java SE 8, where we don't have Flow.*
classes available. The plan is to do whatever is needed to be able to
work with flows without having them. Please see original email where we
are trying to describe it in more detail:
https://java.net/projects/jax-rs-spec/lists/jsr370-experts/archive/2017-01/message/133
Also, couple days back, we created an "integrations" example, which
should remind us what will be necessary to do when working with other
frameworks:
https://github.com/jax-rs/api/blob/nio/examples/src/main/java/jaxrs/examples/nio/Integrations.java
(it is not complete by any means, the message is "we know that we need
to be able to integrate with other frameworks and we are trying to find
the best way").
Mono could help with some implementation issues, especially related to
caching and the decision whether the entity is a collection of POJOs or
just a single POJO. Mono would always be a Publisher (or Source, in
current JAX-RS terminology), so it shouldn't be any harder to integrate it.
Anyway, I'm not saying we need to have a Mono, I'm just asking for an
opinion :-) Thank you for providing one!
Best regards,
Pavel
On 17/03/2017 11:06, mpaluch_at_paluch.biz wrote:
> Hi Pavel,
>
> It's great to see JAX-RS picking up Java 9's Flow API (Reactive
> Streams).
> I'm not EG member but I wanted to share my perspective on Flow API
> usage
> with you.
>
> Flow.Publisher et al are contract interfaces that define a very
> specific
> contract between publishers, subscribers, subscriptions and processors
> along with a spec how the individual components should behave [0] and
> TBCH,
> it's nothing that should be touched from a change perspective.
> `Publisher`
> isn't intended to be used directly with User API but rather via
> implementations such as Project Reactor, RxJava 2, Akka Streams and
> others.
>
> Introducing new interfaces makes it impossible for existing
> implementations
> to adopt JAX-RS-specific interfaces to just play well with your spec.
> Reactive types are as-is. It makes no sense to add something like Mono,
> Single or Maybe to your spec but it makes a lot of sense from the user
> API
> to use these types with the implementation (Jersey, Resteasy) together
> with
> a Reactive Streams implementation.
>
> I'm also not a fan of seeing duplications of Flow inside of JAX-RS
> because
> of the aforementioned reasons.
>
> Cheers,
> Mark
>
>
> [0]
> https://github.com/reactive-streams/reactive-streams-jvm/tree/master/tc
> k