I did not understand the CompletableStage, and i may be asking the wrong
question.
The use of the CompletableStage is to obtain an Asynchronous IO return of
the JAX-RS Service ?
Regards,
Evaldo Junior
---------- Mensagem encaminhada ----------
From: Evaldo Antonio Pinto Junior <evaldoapjunior_at_gmail.com>
To: jsr370-experts_at_jax-rs-spec.java.net
Cc:
Date: Fri, 13 Jan 2017 05:45:06 -0200
Subject: Re: [jax-rs-spec users] Re: JAX-RS 2.1 - work schedule
I am novice to the JSR group. I did not understand the CompletableStage,
and i may be asking the wrong question.
The use of the CompletableStage is to obtain an Asynchronous IO return of
the JAX-RS Service ?
Evaldo Junior
2017-01-12 18:03 GMT-02:00 Sergey Beryozkin <sberyozkin_at_talend.com>:
> 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)
>
> Sergey
>
>
> 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 [ <sberyozkin_at_talend.com>
> mailto:sberyozkin_at_talend.com <sberyozkin_at_talend.com>]
> *Sent:* Donnerstag, 12. Januar 2017 18:56
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> *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 [ <santiago.pericasgeertsen_at_oracle.com>
> mailto:santiago.pericasgeertsen_at_oracle.com
> <santiago.pericasgeertsen_at_oracle.com>]
> *Sent:* Donnerstag, 12. Januar 2017 16:00
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> *Subject:* Re: [jax-rs-spec users] JAX-RS 2.1 - work schedule
>
>
>
>
>
> On Jan 11, 2017, at 4:17 PM, Pavel Bucek <pavel.bucek_at_oracle.com> 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] https://java.net/projects/jax-rs-spec/sources/api/conten
> t/jaxrs-api/src/main/java/javax/ws/rs/client/Invocation.java
>
>
>
>
>
>
>
>