RxJavaAPI 与 Java9流 API 的区别

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

在 Java9中，我们有类似于 RxJava 的 可流动 API的 流程 API，但是在 Java9中有一组更简单的类和接口。

爪哇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，它们似乎做着类似的事情。

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

16425 次浏览
小开

“这两个图书馆之间的主要区别是什么?”

正如您自己提到的，Java9库更加基本，基本上充当反应流的通用 API，而不是成熟的解决方案。

“为什么会有人使用 Java9 Flow 库而不是更加多样化的 RxJava 库，反之亦然?”

好吧，出于同样的原因，人们使用基本的库构造而不是库——少了一个需要管理的依赖关系。而且，由于 Java9中的 FlowAPI 更加通用，所以它受特定实现的限制更少。

小开

起初，有 Rx，第一版。它是一个语言无关的反应性 API 规范，具有 Java、 JavaScript、。NET.然后他们改进了它，我们看到了 Rx 2。它也有不同语言的实现。在 Rx2开发时，Spring 团队正在开发他们自己的一套反应 API —— 反应堆。

然后他们都想: 为什么不共同努力，创建一个 API 来统治他们所有人呢。反应公共资源就是这样建立起来的。建立高度优化的反应流兼容运营商的联合研究工作。当前的实现包括 RxJava2和 Reactor。

同时，JDK 开发人员认识到，反应性的东西是伟大的，值得包括在 Java 中。正如在 Java 世界中通常的做法一样，行业标准成为法律上的事情。还记得 Hibernate 和 JPA，Joda Time 和 Java8 Date/Time API 吗？因此，JDK 开发人员所做的就是提取反应性 API 的最核心、最基本的部分，并使其成为一个标准。j.u.c.Flow就是这样诞生的。

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

我希望，这回答了“它们之间有什么区别”的问题。

为什么会有人选择 j.u.c.Flow而不是 Rx? 因为现在它是一个标准！

目前 JDK 只提供了一个 j.u.c.Flow实现: HTTP/2 API。它实际上是一个正在孵化的 API。但是在将来，我们可能会期望它得到 Reactor、 RxJava2以及其他库的支持，比如反应数据库驱动程序或甚至 FS IO。

小开

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

作为一个信息丰富的注释(但是太长了，不适合) ，负责在 Java9中引入 Flow API 的 JEP 266: 更多并发更新 在它的描述(重点是我的)中说明了这一点

  • 支持 < em > Reactive Streams 发布-订阅的接口 框架 ，嵌套在新的类 流动中

  • Publisher生产产品 由一个或多个 Subscriber消耗，每个 Subscription管理。

  • 通信依赖于一种简单的流控制形式(方法) Subscription.request，用于沟通背压) ，可以是 用于避免在其他情况下可能发生的资源管理问题 基于“推”的系统。提供了一个实用类 SubmissionPublisher 开发人员可以用来创建自定义组件的。

  • 这些(非常 小)接口对应于广泛参与定义的接口 并支持互操作性 横跨许多运行在 JVM 上的异步系统

  • 在类中嵌套接口是一种保守的策略 它们在各种短期和长期可能性中的使用 没有计划提供基于网络或 I/O 的 java.util.concurrent 组件，< em > 但是未来的 JDK 有可能 版本会在其他软件包 .

    中包括这些 API

为什么会有人使用 Java9Flow 库而不使用更多样化的 RxJava 库，反之亦然？

从更广阔的前景来看，这完全是基于诸如客户端正在开发的应用程序类型及其框架用法等因素的观点。

小开
最佳答案

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

Java 9 Flow API 不是一个独立的库，而是 Java 标准版库的一个组件，由4个接口组成，这些接口采用了2015年初建立的 反应流规范。理论上，它的包含可以启用 JDK 内特定的用法，比如孵化 HttpClient，可能是部分计划的异步数据库连接，当然还有 SubmissionPublisher。

RxJava 是一个 Java 库，它使用 ReactiveX 样式的 API 设计来提供一组丰富的反应(推)数据流操作符。版本2，通过 Flowable和各种 XxxProcessor，实现了反应流 API，允许其他兼容库使用 Flowable的实例，反过来，人们可以将任何 Publisher包装成一个 Flowable来使用这些实例，并用它们组成丰富的操作符集。

所以 Reactive Streams API 是 最小接口规范最小接口规范，RxJava2是其中的一个 实施，再加上 RxJava 声明了大量的附加方法来形成它自己的丰富而流畅的 API。

RxJava1启发了 Reactive Streams 规范，但是不能利用它(必须保持兼容性)。RxJava2是一个完整的重写版本和一个单独的主版本，它可以接受和使用 Reactive Streams 规范(甚至在内部扩展它，这要感谢 Rsc项目) ，它比 Java9早了将近一年发布。此外，决定 v1和 v2都继续支持 Java6，因此有很多 Android 运行时。因此，它不能直接利用现在由 Java9提供的流 API，而只能通过 舰桥。其他基于 Reactive Streams 的库也需要和/或提供这种桥接。

RxJava3的目标可能是 Java9 Flow API，但这还没有决定，取决于后续 Java 版本带来的特性(例如，值类型) ，我们可能在一年左右的时间内没有 v3。

在此之前，有一个名为 Reactive4JavaFlow的原型库，它实现了 Flow API，并提供了一个 ReactiveX 风格的丰富流畅的 API。

为什么会有人使用 Java9Flow 库而不使用更多样化的 RxJava 库，反之亦然？

FlowAPI 是一个互操作规范，而不是终端用户 API。通常，您不会直接使用它，而是将流传递给它的各种实现。在讨论 JEP 266时，作者没有发现任何现有库的 API 足够好，可以在 Flow API 中使用缺省值(不像富 java.util.Stream)。因此，决定用户现在必须依赖第三方实现。

您必须等待现有的反应性库通过它们自己的桥实现或要实现的新库原生地支持 Flow API。

在 FlowAPI 上提供一组丰富的操作符是库实现它的唯一原因。数据源供应商(例如，反应式数据库驱动程序，网络库)可以开始通过 Flow API 实现他们自己的数据访问器，并依靠丰富的库来包装这些数据访问器，为它们提供转换和协调，而不必强迫每个人实现各种各样的操作器。

因此，一个更好的问题是，您是现在就开始使用基于 Flow API 的互操作，还是继续使用 Reactive Streams？

如果您需要工作和可靠的解决方案相对较快，我建议您现在坚持使用 Reactive Streams 生态系统。如果您有足够的时间或者想要探索一些东西，您可以开始使用 Flow API。


提交答案