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

【问题标题】：Difference between RxJava API and the Java 9 Flow APIRxJava API 和 Java 9 Flow API 之间的区别
【发布时间】：2018-05-01 11:27:57
【问题描述】：

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

在 Java 9 中，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 rx-java rx-java2 java-9

【解决方案1】：

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

Java 9 Flow API 不是一个独立的库，而是 Java 标准版库的一个组件，由 2015 年初制定的 Reactive Streams 规范采用的 4 个接口组成。理论上，它的包含可以启用特定于 JDK 的使用，例如孵化的 HttpClient，可能是计划中的异步数据库连接，当然还有SubmissionPublisher。

RxJava 是一个 Java 库，它使用 ReactiveX 风格的 API 设计来为反应式（推送）数据流提供一组丰富的运算符。版本 2，通过 Flowable 和各种 XxxProcessors，实现了反应式流 API，它允许 Flowable 的实例被其他兼容库使用，然后可以将任何 Publisher 包装到 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，只能通过bridge。其他基于 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 有一些默认设置（与丰富的 java.util.Stream 不同）。因此，决定用户现在必须依赖 3rd 方实现。

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

通过 Flow API 提供一组丰富的运算符是库实现它的唯一原因。数据源供应商（即响应式数据库驱动程序、网络库）可以开始通过 Flow API 实现他们自己的数据访问器，并依靠丰富的库来包装它们并为它们提供转换和协调，而无需强迫每个人都实现各种这些操作符.

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

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

【讨论】：

【解决方案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 日期/时间 API 吗？因此，JDK 开发人员所做的就是提取反应式 API 的核心，这是最基本的部分，并使其成为标准。 j.u.c.Flow 就是这样诞生的。

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

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

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

目前 JDK 仅提供 j.u.c.Flow 的一种实现：HTTP/2 API。它实际上是一个孵化 API。但在未来，我们可能会期望 Reactor、RxJava 2 以及其他库（如响应式 DB 驱动程序甚至 FS IO）支持它。

【讨论】：

您将一些事件混为一谈。在 RxJava 0.x 变得足够稳定之后，Reactive Streams 计划成为聚集点。 Reactive Streams Commons 于 2016 年初推出，目标是您正确陈述的。

【解决方案3】：

“这两个库的主要区别是什么？”

正如您自己所指出的，Java 9 库更加基础，基本上用作反应流的通用 API，而不是完整的解决方案。

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

嗯，出于同样的原因，人们使用基本的库结构而不是库 - 需要管理的依赖项更少。此外，由于 Java 9 中的 Flow API 更通用，因此受具体实现的约束较少。

【讨论】：

【解决方案4】：

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

这主要是作为一个信息性评论（但太长而无法放入），JEP 266: More Concurrency Updates 负责在 Java9 中引入 Flow API在其描述中说明了这一点（强调我的） -

支持响应式流发布-订阅的接口框架，嵌套在新类Flow中。
Publishers 生产物品由一个或多个Subscribers 使用，每个Subscription 管理。
通信依赖于一种简单形式的流控制（方法 Subscription.request，用于传达背压）可以用于避免可能发生的资源管理问题基于“推”的系统。提供了一个实用程序类SubmissionPublisher 开发人员可以用来创建自定义组件。
这些（非常 small) 接口对应于广泛参与定义的接口（来自 Reactive Streams 倡议）并支持互操作性跨多个在 JVM 上运行的异步系统。
将接口嵌套在一个类中是一个允许的保守策略它们在各种短期和长期可能性中的使用。那里没有计划提供基于网络或 I/O 的java.util.concurrent 用于分布式消息传递的组件，但未来的 JDK 可能版本将在其他包中包含此类 API。

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

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

【讨论】：