Markus,
sorry, I'm a bit tired (and sick) today, so may be I've missed
something, but no, I do not support your arguments.
Having a good standard is good, agreed. And having a standard which is
clever enough to let people work with a standard
API, while in this case, being able optionally to support RxJava or
something else that will come tomorrow, is a massive plus.
I know firsthand, 100%, that JAX-RS is losing to Spring WS/RS in some
cases. It is not only about creating a standard for the sake of creating
a standard
but is about creating a standard which will stay alive and competitive.
I do encourage you to actually have a look at the proposed RxInvoker and
check the examples, there was also a good Jersey blog awhile back on
their prototype of working with RxJava which I reckon led to RxInvoker
idea...
Sergey
On 13/01/17 19:02, Markus KARG wrote:
>
> I understand your arguments and I hope you understand mine too. As I
> am a member of the JCP solely for the sake of creating industrial
> standars (hence not of creating products), I have a slightly differen
> view of this. I think it is critical that JAX-RS stays focused on
> long-term evolution instead of extensibity of the current evolutionary
> step.
>
> The question now is, somebody has to decide what the final API shall
> be like: (even slightly) more complex for each code line where it is
> getting used but for the sake of being extendable - vs. - concise (and
> slightly higher performant) - vs. - both variants. My vote is that we
> only support CompletableStage in JAX-RS 2.1, and come up with
> additional Java-10-native-RX-API support in JAX-RS 3.0 or 3.1, but not
> to keep the API pluggable for any product that is not standardized by
> the JCP while ALL (!) OTHER APIs of Java EE do not care the least
> about those products (independent of their popularity).
>
> A second issue I can remember is that I asked whether it makes sense
> to directly request a reactive client once (i. e. all further calls
> bear CompletableStage), or whether we really want users to request a
> reactive invocation for each and every invocation. I cannot remember
> that _that_ discussion ended with any concensus.
>
> But the question is, whether the Spec Lead decides that alone without
> further discussion of the EG members, or whether the EG members have a
> real say in that as in a democratic project. This is something
> Santiago has to tell us. See, I don't want to bother, I actually just
> want to have clear rules to follow. The JCP says, the EG defines the
> outcome. So we should at least shortly discuss the pros and cons of
> different API variants as other JSRs do, too, and not just nod through
> one single proposal for the sole sake of getting done earlier.
>
> -Markus
>
> *From:*Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> *Sent:* Donnerstag, 12. Januar 2017 21:04
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> *Subject:* Re: [jax-rs-spec users] JAX-RS 2.1 - work schedule
>
> 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 [mailto:sberyozkin_at_talend.com]
> *Sent:* Donnerstag, 12. Januar 2017 18:56
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> <mailto: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
> [mailto:santiago.pericasgeertsen_at_oracle.com]
> *Sent:* Donnerstag, 12. Januar 2017 16:00
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> <mailto: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
> <mailto: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/content/jaxrs-api/src/main/java/javax/ws/rs/client/Invocation.java
>