> On Oct 19, 2015, at 4:11 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
>
> The use of an rx() fits better with the rest of the fluent API. It is just another “modifier” like async(), that is, just another “invoker”. If you start from ClientBuilder, then why not do that for other invokers?
>
> In fact, the person that designed the original Jersey API liked this approach better as well, especially for the JAX-RS API.
>
> I see your point, but there is a difference between async and rx from a conceptional view: Typically one will write a complete application in a reactive style COMPLETELY and will not mix reactive and non-reactive style in one single application (this would be like a hybrid using OOP and non-OOP). So it makes not much sense to repeat the rx() again and again. async is actually decided per method, as typically most methods are non-async but only SOME are async. So rx() makes sense when building a client, while async() typically makes sense only when building an invocation.
I don’t agree with your argument. Look, this is what you can do in 2.0:
Future<String> f = target.request().async().get(String.class);
This is the new proposal in 2.1:
CompletableStage<String> f = target.request().rx().get(String.class);
Symmetric, and easy to understand. No need to create a new path starting from Client that developers aren’t familiar with. The Invoker idea was an extension point created for this.
> Easy, only Java 8. I think reactive APIs are still evolving, so an extension point to allow future APIs to work with JAX-RS (without the need to rev the spec) would be useful.
>
> I understand your vision, but the question is, whether we can provide a simple Java 8 support without adding the complexity needed solely for the sake of future flexibility? I mean, this goes a bit into premature optimization in the sense of D. E. Knuth: Wouldn't it be evil to specify an extension point before we know that we really will need it in future? What if Java 10 comes with a full-monty reactive support that completely is built ontop of CompletableStage, and no other framework actually will be of broad interest? We will then have to maintain a complexity level that is not needed.
I think RxJava may be of interest to a lot of people. Extension points and premature optimization are unrelated.
>
> * The code snipped Santiago was pointing to does not showcase how to use RX on server side. In particular, it might be useful to glue together pending CompletableFutures with @Asynchronous,
>
> @Asynchronous is not part of JAX-RS, only Jersey. Other examples using AsyncResponse are very easy to write.
>
> Do you have some example at hand which you can disclose so we better understand what your plans on server side are?
Maybe I misunderstood what you meant by RX on the server side. RX support is for the client. Of course, servers can be clients as well, in which case you may want to use AsyncResponse in your resource method. That is what I meant.
— Santiago
>> From: Santiago Pericasgeertsen [mailto:santiago.pericasgeertsen_at_oracle.com <mailto:santiago.pericasgeertsen_at_oracle.com>]
>> Sent: Montag, 12. Oktober 2015 16:30
>> To: jsr370-experts_at_jax-rs-spec.java.net <mailto:jsr370-experts_at_jax-rs-spec.java.net>
>> Subject: Drafts for Rx, NIO and SSE
>>
>> Dear Experts,
>>
>> My apologies for sending all these drafts in one shot, but I feel we need to start making progress quickly if we want to produce an EDR in a few months.
>>
>> The following pull request [1] includes proposals for Rx, NIO and SSE. Let me point you to the examples to get you started:
>>
>> (1) Rx:
>>
>> https://github.com/spericas/api/blob/master/jaxrs-api/src/test/java/javax/ws/rs/core/RxClientTest.java <https://github.com/spericas/api/blob/master/jaxrs-api/src/test/java/javax/ws/rs/core/RxClientTest.java>
>>
>> This is an extension to our Client API that integrates with the CompletableFuture API in JDK 8 (note that CompletionStage is a super type of CompletableFuture). The proposal is extensible and can use other APIs similar to CompletableFuture —see the optional parameter to the rx() method for that purpose. The spec will only mandate support for CompletableFuture, but implementations are free to provide support for other APIs, such as RxJava.
>>
>> (2) NIO:
>>
>> https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResource.java <https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResource.java>
>> https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResourceClient.java <https://github.com/spericas/api/blob/master/examples/src/main/java/jaxrs/examples/nio/FileResourceClient.java>
>>
>> On the server side, the proposal follows the pattern set by StreamingOutput, but of course using lambdas this time around. As you know, Servlet already supports NIO, but with a completely different API.
>>
>> (3) SSE:
>>
>> https://github.com/mpotociar/api/tree/master/examples/src/main/java/jaxrs/examples/sse <https://github.com/mpotociar/api/tree/master/examples/src/main/java/jaxrs/examples/sse>
>>
>> Note that like in NIO, there are proposed extensions to both the Client and Server APIs for SSE.
>>
>> I understand that this is a lot to digest, so feel free to start new e-mail threads to discuss each one independently. I just felt it was important to start all these discussions ASAP.
>>
>> — Santiago
>>
>> [1] https://github.com/jax-rs/api/pulls <https://github.com/jax-rs/api/pulls>