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>:
> 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]
> *Sent:* Freitag, 13. Januar 2017 20:56
> *To:* 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>:
>
> 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
> <sberyozkin_at_talend.com>]
> *Sent:* Donnerstag, 12. Januar 2017 18:56
> *To:* 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 <santiago.pericasgeertsen_at_oracle.com>]
> *Sent:* Donnerstag, 12. Januar 2017 16:00
> *To:* 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> 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
>
>
>
>
>
>
>
>
>
>
>
>
>