users@jax-rs-spec.java.net

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Sat, 14 Jan 2017 10:41:50 +0000

So the users will have to register somewhere else the factories, how will they do it and where is a win, in terms of the simplification ? Putting some META-INF files is not worth considering IMHO, it is anti-dynamic.
I agree people will not want mix 2 styles of RxJava in one piece of code but they should be able to select it from the code fast, once only, which is what the current proposal offers.

Sergey

On 13/01/17 23:19, Ondrej Mihályi wrote:
Actually, I like the unwrap method more than the current proposal. It makes it explicit what I want to get when I write code. The current proposal is similar, but requires me to remember the name of the invoker on top of the rx interface I want to get.

Compare:

Current proposal

CompletionStage<List<String>> cs = client.request()
                .rx(CompletionStageRxInvokerProvider.class)
                .get(new GenericType<List<String>>() {
                });



With unwrap

CompletionStage<List<String>> cs = client.request()
                .rx().unwrap(CompletionStage.class)
                .get(new GenericType<List<String>>() {
                });


... provided that a suitable provider for CompletionStage (or any other rx interface) is configured using SPI.




to have an SPI that statically defines the return type of rx().

I don't get this. How can an SPI define the return type? Markus, could you please give a code sample?




Ondrej


2017-01-13 23:10 GMT+01:00 Markus KARG <markus_at_headcrashing.eu<mailto:markus_at_headcrashing.eu>>:
Ondrej,

thank you for sharing your opinion.

I am not against extensibility nor plugability, but against the particular draft "rx(Client)".

Months back I proposed to instead provide an SPI that switches the outcome of rx() to a different time, this is much better, as within the same program nobody ever wants to write things like "rx(TypeA.class); rx(TypeB.class); rx(TypeC.class);" which the API not only allows, but actually enforces.

A much better way is to write "Client.rx().unwrap(Type.class)" (as you propose and looks promising to me), or to have an SPI that statically defines the return type of rx().

I hope it is clear now what I do criticize and what not.

-Markus

From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com<mailto:sberyozkin_at_talend.com>] Sent: Freitag, 13. Januar 2017 20: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] Re: JAX-RS 2.1 - work schedule

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] 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