jsr370-experts@jax-rs-spec.java.net

RE: [jax-rs-spec users] Re: Suggestion to refactor rx invoker API

From: Markus KARG <markus_at_headcrashing.eu>
Date: Sat, 14 Jan 2017 17:29:04 +0100

You do not need the parameter, and you do not need to cast. It is pretty valid Java syntax and it is fluent to write

Classname.<Typename>unwrap() to statically type the result of the unwrap method at compile time.

 

-Markus

 

From: Ondrej Mihályi [mailto:ondrej.mihalyi_at_gmail.com]
Sent: Samstag, 14. Januar 2017 15:51
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: [jax-rs-spec users] Re: Suggestion to refactor rx invoker API

 

Yes, naming it unwrap() is OK for me.

We could also have a method without any argument, but I think we still need a method with an argument for type inference, so that it is possible to chain methods in fluent API. Having only a method <T> T unwrap() would be usable only if its result is assigned to a variable, forcing people to break the fluent code. Or they would need to use type conversion like ((Type)rx().unwrap()), which requires too many brackets and is error-prone.

Ondrej

 

2017-01-14 15:28 GMT+01:00 Markus KARG <markus_at_headcrashing.eu>:

Sounds good for me, but actually I think it would be even simpler if we name it "unwrap()", and do not fill in any parameters. As I said, I think applications will typically use only one technology at the time. So "unwrap()" simply can check if there is a @Provider registered having a method with the same parameters as your proposed "conver()", we finally have the requested plugability, no additonal complexity, follow existing JAX-RS patterns, and get rid of repeating lots of "rx(Class)". :-)

 

-Markus

 

 

From: Ondrej Mihályi [mailto:ondrej.mihalyi_at_gmail.com]
Sent: Samstag, 14. Januar 2017 12:54
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Suggestion to refactor rx invoker API

 

I was thinking about an alternative to current rx API, to simplify it in context of supporting extensibility.

My idea is to modify the CompletionStageRxInvoker, so that it returns an extension to CompletionStage, which would contain additional method to convert the interface to any other reactive interface:

public interface RxCompletionStage<T> extends CompletionStage<T> {
    <NEW> NEW convert(Function<CompletionStage<T>, NEW> converter);
}

With this, we would move all the complexity to this new interface, which still can be used as a usual CompletionStage, but with the additional convert method, it provides an extension point to other interfaces. And it's based on standard CompletionStage, therefore we don't need additional rx invokers.

We could remove RxInvokerProvider, the 2 rx() methods from the Builder, which accept RxInvokerProvider, and even remove the RxInvoker interface, as CompletionStageRxInvoker would be the only required implementation.

 

Here is an example of what I mean, with RxJava2 as an example:

client.request().rx().get(). // we get the RxCompletionStage here, which extends CompletionStage
    .convert(this::flowableFromStage) // accepts a function that converts the CompletionStage to another interface
    .subscribe(s -> testResult = s, Throwable::printStackTrace);
An example of a working code here <https://github.com/OndrejM-demonstrations/JavaEEReactive/blob/rxjava/src/test/java/reactivejavaee/CompletionStageRxJavaTest.java#L120> (although not using JAX-RS, just wrapping a method that returns a CompletionStage).
Ondrej