RxJava API和Java 9 Flow API之间的区别

Question

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

在Java 9中,我们有Flow API,类似于RxJava的Flowable API,但Java 9有一组更简单的类和接口.

Java 9

有Flow.Publisher,Flow.Subscriber,Flow.Processor,Flow.Subscription,和SubmissionPublisher,这就是它.

RxJava

拥有全包的流API状类,即io.reactivex.flowables,io.reactivex.subscribers,io.reactivex.processors,io.reactivex.observers,和io.reactivex.observables这似乎做同样的事情.

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

Answer 1

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

Java 9 Flow API不是一个独立的库,而是Java Standard Edition库的一个组件,由2015年初建立的Reactive Streams规范采用的4个接口组成.理论上,它包含在内可以实现in-JDK特定的用法,例如孵化HttpClient,可能是部分计划的异步数据库连接,当然还有SubmissionPublisher.

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

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

除了其他来源之外,RxJava 1还启发了Reactive Streams规范,但无法利用它(必须保持兼容).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.

为什么有人会使用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.

Answer 2

起初,有一个Rx,版本一.它是反应API的语言无关规范,具有Java,JavaScript,.NET的实现.然后他们改进了它,我们看到了Rx 2.它还具有不同语言的实现.在Rx 2时,Spring团队正在研究Reactor - 他们自己的一系列反应API.

然后他们都在想:为什么不共同努力并创建一个API来统治它们.这就是Reactive Commons的成立方式.联合研究工作,用于构建高度优化的反应流兼容运营商.当前的实现者包括RxJava2和Reactor.

与此同时,JDK开发人员意识到反应性的东西很棒,值得用Java包含.正如在Java世界中常见的那样,事实上的标准在法律上变得非常重要.记得Hibernate和JPA,Joda Time和Java 8 Date/Time API？因此JDK develpers所做的就是提取最活跃的API的核心,这是最基本的部分,并使其成为标准.那是怎么j.u.c.Flow诞生的.

从技术上讲,j.u.c.Flow它要简单得多,它只包含四个简单的接口,而其他库则提供了数十个类和数百个运算符.

我希望,这回答了"他们之间有什么区别"的问题.

为什么有人会选择j.u.c.FlowRx？好吧,因为现在它是一个标准!

目前JDK只提供了一个实现j.u.c.Flow:HTTP/2 API.它实际上是一个孵化API.但是在未来我们可能期望从Reactor,RxJava 2以及其他库中获得支持,例如反应式DB驱动程序甚至FS IO.

Answer 3

"这两个图书馆之间的主要区别是什么？"

正如您自己所说,Java 9库更加基础,基本上可以作为反应流的通用API,而不是完整的解决方案.

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

好吧,出于同样的原因,人们使用基本的库构造而不是库 - 一个较少的依赖管理.此外,由于Java 9中的Flow API更为通用,因此受特定实现的约束较少.

Answer 4

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

这主要是一条信息性评论（但太长而无法适应），JEP 266：负责Flow在 Java9 中引入API 的更多并发更新在其描述中说明了这一点（强调我的） -

• 支持Reactive Streams 发布订阅框架的接口，嵌套在新类Flow 中。

• Publishers 生产一个或多个Subscribers消耗的物品，每个物品由 a 管理Subscription。

• 通信依赖于一种简单形式的流控制（方法 Subscription.request，用于通信背压），可用于避免在基于“推送”的系统中可能出现的资源管理问题。SubmissionPublisher提供了一个实用程序类，开发人员可以使用它来创建自定义组件。

• 这些（非常小的）接口对应于那些广泛参与（来自 Reactive Streams 计划）定义的接口，并支持在 JVM 上运行的许多异步系统之间的互操作性。

• 将接口嵌套在一个类中是一种保守的策略，允许它们在各种短期和长期的可能性中使用。没有计划java.util.concurrent 为分布式消息传递提供基于网络或 I/O 的组件，但未来的 JDK 版本可能会在其他包中包含此类 API。

_{为什么有人会使用 Java 9 Flow 库而不是更加多样化的 RxJava 库，反之亦然？}

从更广阔的前景来看，这完全是基于客户正在开发的应用程序类型及其对框架的使用等因素的意见。