[jax-rs-spec users] Re: JAX-RS 2.1 - work schedule

From: Sergey Beryozkin <>
Date: Thu, 12 Jan 2017 20:03:35 +0000

Have a look please at the proposed API, rx() is simply a bridge into a
CompletableStage, while another rx(...) overload (which I have some
separate techincail issues with) will let users plug-in other reactive
implementations, while still working with JAX-RS 2.1 API - only a type
variable will differ. IMHO it is critical JAX-RS stays more open (rx()
and rx(...) is a good example)


On 12/01/17 19:06, Sergey Beryozkin wrote:
> Standards, standards. You keep forgetting that today many users do not
> care about standards but about being able to use the good, proven to
> work technologies in their work.
> We should learn from Spring WS/REST.
> > In the end, what we decide, is frozen for decades. I mean, that's a
> difference between breeding an international standard and simply
> providing a good API _for now_.
> The standard which noone will use ? rx() will not force people to use
> what you do not consider a proper standard
> On 12/01/17 18:53, Markus KARG wrote:
>> RxJava is not a JCP standard, and popularity can change easily. So it
>> is doubtful whether non-standards have to be taken core of by
>> standards. I cannot see any other JCP standard that enforces a detour
>> in the API just for the sake of supporting non-standards. Correct me
>> if I am wrong. A better way would be defining an SPI, or
>> configuration, too statically choose in the bootstrat. I doubt that
>> applications will mix differen RX implementations at runtime, so
>> there is no need to say "I want RxJava" with every single call of the
>> API.
>> Yes, Java 10. I heared that it might provide an official RX standard
>> for Java SE. So JAX-RS "3+" might be facing a situation whethere it
>> has to support an official standard. We have to take care that
>> decisions for JAX-RS today must not stand in the way of usefulness
>> and conciseness of JAX-RS in the future. I hardly think that in two
>> or three years people like the idea that they have to write
>> "rx(Classname)" always if possibly Java 10's reactive API took over
>> and nobody talks about CompletableStage and RxJava anymore.
>> In the end, what we decide, is frozen for decades. I mean, that's a
>> difference between breeding an international standard and simply
>> providing a good API _for now_.
>> Markus
>> *From:*Sergey Beryozkin []
>> *Sent:* Donnerstag, 12. Januar 2017 18:56
>> *To:*
>> *Subject:* Re: [jax-rs-spec users] JAX-RS 2.1 - work schedule
>> Java 10 ? JAX-RS 2.1 is Java 8 based, and RxJava is highly popular so
>> voluntarily restricting 2.1. to CompletableStage only would be a
>> mistake...
>> Sergey
>> On 12/01/17 17:10, Markus KARG wrote:
>> The question is whether we actually want the ability to support
>> other reactive implementations, or whether we decide to stick
>> with CompletableStage? The rx intermediate method makes the API
>> more complex for anybody. On the other hand, Java 10 possibly
>> will provide a "real" reactive API for everyone, and we cannot
>> natively support it, but enforce people to use rx() still, which
>> is tedious. I cannot remember that the EG actually agreed upon a
>> final answer of this dilemma.
>> *From:*Santiago Pericasgeertsen
>> []
>> *Sent:* Donnerstag, 12. Januar 2017 16:00
>> *To:*
>> <>
>> *Subject:* Re: [jax-rs-spec users] JAX-RS 2.1 - work schedule
>> On Jan 11, 2017, at 4:17 PM, Pavel Bucek
>> < <>> wrote:
>> So what's going to happen next? We are currently working in
>> PoC implementation of Reactive client API which is currently
>> in the JAX-RS source repository master branch - it is almost
>> ready for review. We identified small improvement needed
>> there and I'm going to take care of that, finish the PoC
>> implementation and document the API on the wiki. Once this is
>> done, I'll send a request for review to this mailing list.
>> Just a quick reminder that the crux of the RX work is the
>> addition of new rx() methods to Invocation, with default support
>> for CompletionStage and an extension point to plug in other
>> reactive implementations via the RxInvoker type [1].
>> — Santiago
>> [1]