RxJava API和Java 9 Flow API之间的区别 [英] Difference between RxJava API and the Java 9 Flow API

查看:1539
本文介绍了RxJava API和Java 9 Flow API之间的区别的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在最近几个主要版本的Java的每次迭代中,似乎都有新的方法来管理并发任务。



在Java 9中,我们有< a href =https://docs.oracle.com/javase/9​​/docs/api/index.html?java/util/concurrent/Flow.html\"rel =noreferrer> Flow API ,类似于RxJava的 Flowable API 但是使用Java 9有一个更简单的类和接口集。



Java 9



有一个 Flow.Publisher Flow.Subscriber Flow.Processor Flow.Subscription SubmissionPublisher ,就是这个。



RxJava



整个 Flow API 类,即 io。 reactivex.flowables io.reactivex.subscribers io.reactivex.processors io.reactivex.observers io.reactivex.observables 似乎做了类似的事情。



这两个图书馆之间的主要区别是什么?为什么有人会使用Java 9 Flow库而不是更多样化的RxJava库?反之亦然?

解决方案


这两个库之间的主要区别是什么?


Java 9 Flow API不是一个独立的库,而是一个组件Java标准版库,包含4个接口,这些接口来自 Reactive Streams 规范。从理论上讲,它的包含可以启用in-JDK特定用法,例如孵化HttpClient,可能是部分计划的异步数据库连接,当然还有 SubmissionPublisher 。 / p>

RxJava是一个Java库,它使用ReactiveX风格的API设计,在响应(推送)数据流上提供丰富的运算符。版本2,通过 Flowable 和各种 XxxProcessor ,实现了Reactive Streams API,它允许 Flowable 将由其他兼容库使用,反过来可以将任何 Publisher 包装到 Flowable 使用它们并用它们组成丰富的运算符。



因此Reactive Streams API是最小接口规范和RxJava 2是它的一个实现,另外RxJava声明了一大堆额外的方法来形成自己的丰富和流畅的API。



RxJava 1在其他来源中受到了反应流规范的启发,但无法利用它(必须保持兼容)。 RxJava 2是一个完全重写和独立的主要版本,可以包含并使用Reactive Streams规范(甚至可以在内部进行扩展,这要归功于 Rsc 项目)并且已经在Java 9发布前差不多一年了。此外,还决定v1和v2都支持Java 6,从而支持很多Android运行时。因此,它无法直接利用Java 9现在提供的Flow API,而只能通过网桥。此类桥接器也是其他基于Reactive Streams的库所需和/或提供的。



RxJava 3可能针对Java 9 Flow API但尚未确定并且根据后续Java版本带来的功能(即值类型),我们可能在一年左右的时间内没有v3。



到那时,有一个原型名为 Reactive4JavaFlow 的库,它实现了Flow API并在其上提供了ReactiveX风格的丰富的流畅API。 / p>


为什么有人会使用Java 9 Flow库而不是更多样化的RxJava库,反之亦然?


Flow API是一种互操作规范,而不是最终用户API。通常,您不会直接使用它,而是将流传递给它的各种实现。在讨论JEP 266时,作者没有发现任何现有的库的API足以使Flow API具有默认值(与rich java.util.Stream 不同)。因此,决定用户现在必须依赖第三方实现。



您必须等待现有的反应库本地支持Flow API,通过他们的自己的桥实现或要实现的新库。



通过Flow API提供丰富的运算符只是库实现它的原因。数据源供应商(即,反应式数据库驱动程序,网络库)可以通过Flow API开始实现自己的数据访问器,并依靠丰富的库来包装它们并为它们提供转换和协调,而不必强迫每个人实现各种这些运算符。



因此,更好的问题是,您现在应该开始使用基于Flow API的互操作还是坚持使用Reactive Streams?



如果您需要相对较快地使用可靠且可靠的解决方案,我建议您现在坚持使用Reactive Streams生态系统。如果您有足够的时间或者想要探索事物,可以开始使用Flow API。


It seems on every iteration of Java for the last few major releases, there are consistently new ways to manage concurrent tasks.

In Java 9, we have the Flow API which resembles the Flowable API of RxJava but with Java 9 has a much simpler set of classes and interfaces.

Java 9

Has a Flow.Publisher, Flow.Subscriber, Flow.Processor, Flow.Subscription, and SubmissionPublisher, and that's about it.

RxJava

Has whole packages of Flow API-like classes, i.e. io.reactivex.flowables, io.reactivex.subscribers, io.reactivex.processors, io.reactivex.observers, and io.reactivex.observables which seem to do something similar.

What are the main differences between these two libraries? Why would someone use the Java 9 Flow library over the much more diverse RxJava library or vice versa?

解决方案

What are the main differences between these two libraries?

The Java 9 Flow API is not a standalone library but a component of the Java Standard Edition library and consists of 4 interfaces adopted from the Reactive Streams specification established in early 2015. In theory, it's inclusion can enable in-JDK specific usages, such as the incubating HttpClient, maybe the planned Async Database Connection in parts, and of course SubmissionPublisher.

RxJava is Java library that uses the ReactiveX style API design to provide a rich set of operators over reactive (push) dataflows. Version 2, through Flowable and various XxxProcessors, implements the Reactive Streams API which allows instances of Flowable to be consumed by other compatible libraries and in turn one can wrap any Publisher into a Flowable to consume those and compose the rich set of operators with them.

So the Reactive Streams API is the minimal interface specification and RxJava 2 is one implementation of it, plus RxJava declares a large set of additional methods to form a rich and fluent API of its own.

RxJava 1 inspired, among other sources, the Reactive Streams specification but couldn't capitalize on it (had to remain compatible). RxJava 2, being a full rewrite and a separate main version, could embrace and use the Reactive Streams specification (and even expand upon it internally, thanks to the Rsc project) and has been released almost a year before Java 9. In addition, it was decided both v1 and v2 keeps supporting Java 6 and thus a lot of Android runtimes. Therefore it couldn't capitalize directly on the Flow API provided now by Java 9 directly but only through a bridge. Such bridge is required by and/or provided in other Reactive Streams-based libraries too.

RxJava 3 may target the Java 9 Flow API but this hasn't been decided yet and depending on what features the subsequent Java versions bring (i.e., value types), we may not have v3 within a year or so.

Till then, there is a prototype library called Reactive4JavaFlow which does implement the Flow API and offers a ReactiveX style rich fluent API over it.

Why would someone use the Java 9 Flow library over the much more diverse RxJava library or vice versa?

The Flow API is an interoperation specification and not an end-user API. Normally, you wouldn't use it directly but to pass flows around to various implementations of it. When JEP 266 was discussed, the authors didn't find any existing library's API good enough to have something default with the Flow API (unlike the rich java.util.Stream). Therefore, it was decided that users will have to rely on 3rd party implementations for now.

You have to wait for existing reactive libraries to support the Flow API natively, through their own bridge implementation or new libraries to be implemented.

Providing a rich set of operators over the Flow API is only reason a library would implement it. Datasource vendors (i.e., reactive database drivers, network libraries) can start implementing their own data accessors via the Flow API and rely on the rich libraries to wrap those and provide the transformation and coordination for them without forcing everybody to implement all sorts of these operators.

Consequently, a better question is, should you start using the Flow API-based interoperation now or stick to Reactive Streams?

If you need working and reliable solutions relatively soon, I suggest you stick with the Reactive Streams ecosystem for now. If you have plenty of time or you want to explore things, you could start using the Flow API.

这篇关于RxJava API和Java 9 Flow API之间的区别的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆