On 13/01/17 19:30, Ondrej Mihályi wrote:
> Hi Markus,
>
> I'm not a member of the EG, just a random JCP associate member. But I
> wanted to have a word on this.
>
> I think that having an extendable API is really important for the
> future of Java EE.
+1, I'm not a Java EE expert but yes, for it to stay competitive, it has
to be more open
> It's always been the point to standardize what makes sense to
> standardize, but allow implementations to extend the API. Many Java EE
> APIs provide an "unwrap" method to retrieve provider specific API
> (EntityManager.unwrap(), Validator.unwrap(), etc. )
>
> In what is having a version of rx() method that makes it possible to
> get to a specific reactive API different to those unwrap() methods? Do
> you think it is better to rename the rx() method to unwrap() method to
> be in line with the other specifications?
>
> Ondrej
>
> 2017-01-13 20:02 GMT+01:00 Markus KARG <markus_at_headcrashing.eu
> <mailto:markus_at_headcrashing.eu>>:
>
> 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
> <mailto:sberyozkin_at_talend.com>]
> *Sent:* Donnerstag, 12. Januar 2017 21:04
>
>
> *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
>
> 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
> <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
> <https://java.net/projects/jax-rs-spec/sources/api/content/jaxrs-api/src/main/java/javax/ws/rs/client/Invocation.java>
>
>