RxJava 3 #204
Comments
|
we will investigate this soon and likely provide support for 3, thanks for reporting this. |
|
It seems to me that Rx 3.0 is a bit a joke and it does not bring enough stuff on the table, I see it more as a glorified 2.3.0 than a real 3.0 . A real 3.0 would have embraced Java 8+ at least. |
I agree with you. It seems to me that it is because rxJava is heavily used by Android guys that are stuck in java6 :( |
|
according to the issue in their tracker, people said that Android should not be an issue anymore and they would be fine actually continuing using 2.x |
|
even Java 11 would be nice actually with Flow API |
|
I think the decision to release version 3 instead of 2.3 for example is related to many API changes. What leads me to interpret this are the sentences that states RxJava 2 API mistakes being fixed and also it's limitations. Anyway, I believe that Vert.x will adopt RxJava 3 in due course. |
|
@aaloise yes, ignore the rant where I was just bitching at RxJava 3 due to my disappointment by the lack of ambition |
|
It was discussed here: ReactiveX/RxJava#5620 |
|
In another discussion some argue for using a more recent version of Java: |
|
Must confess that I did not fully understand the decision to stay with Java 6 support. I know there is the whole thing surrounding Android, but I don't know exactly how much support to it is worthy. I think adopting Java 8+ as a minimum, as Reactor did, would enrich the library. But this is one of those design decisions, of which we have no choice but to accept. Regardless, RxJava has great value and I, among others in the community, like to see it talking so well with Vert.x 😊 |
|
Good news! Since version 3.0.0-RC7, RxJava has moved to a Java 8 baseline. |
|
that's a great news @aaloise :-) |
|
however it seems still to use its RX2 interfaces, e.g https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/rxjava3/functions/Consumer.java instead of Java 8 Consumer interface |
|
Let's see how things go, it's still in RC stage. I am not 100% sure, but I think that it has something to do with Android desugar... "For Android development, the latest Android Studio is always recommended which is already able to desugar many Java 8 constructs. The upcoming AS 4 will support even more desugaring for older API levels. Until then, one should stick to the non-Java 8 standard methods so the Java 8 methods can be ignored by AS." |
|
wait and see indeed :-) |
|
@vietj David Karnok explained to me why RxJava 3 still uses it's own interfaces instead the ones of Java 8: "Java functional interfaces can't throw checked exceptions but ours can. If we switched over, a protocol would be needed to sneak out checked exceptions. This adds complications to both our users (try-catch in many lambdas) and library internals (proper unwrapping in a ton of operators). Reactor did it and suffered from related issues for months. Besides, functional interfaces and lambdas can be freely defined. Since the business logic is customized through it every time, I don't think there exist a repository of java functionals so no direct interop is likely needed. Otherwise, use lambda::apply to convert them at your will." |
|
@aaloise interesting thanks |
|
For this generator we should skip the generation of Handler and Future methods and provide only Rx3 types I think, at least we should skip Handler |
|
Is RxJava 3 support planned for Vert.x 4 or postponed to a later Vert.x release? |
|
it is not yet clear, if that's not in Vert.x 4.0 then it would be in 4.1 |
|
instead proper issue #204 |
You have linked this same closed issue |
|
here is the correct one #240 |
The text was updated successfully, but these errors were encountered: