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

Difference between RxJava API and the Java 9 Flow API

提问by Dovmo

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

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

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

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

Java 9

爪哇 9

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

有Flow.Publisher, Flow.Subscriber, Flow.Processor, Flow.Subscription, 和SubmissionPublisher，仅此而已。

RxJava

RxJava

Has whole packagesof Flow API-like classes, i.e. io.reactivex.flowables, io.reactivex.subscribers, io.reactivex.processors, io.reactivex.observers, and io.reactivex.observableswhich seem to do something similar.

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

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?

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

采纳答案by akarnokd

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 Streamsspecification 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.

Java 9 Flow API 不是一个独立的库，而是 Java 标准版库的一个组件，由 4 个采用自2015 年初建立的Reactive Streams规范的接口组成。理论上，它的包含可以启用 JDK 中的特定用法，例如正在孵化的 HttpClient，也许是计划中的异步数据库连接部分，当然还有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 Flowableand various XxxProcessors, implements the Reactive Streams API which allows instances of Flowableto be consumed by other compatible libraries and in turn one can wrap any Publisherinto a Flowableto consume those and compose the rich set of operators with them.

RxJava 是一个 Java 库，它使用 ReactiveX 风格的 API 设计来为响应式（推送）数据流提供一组丰富的操作符。第 2 版通过sFlowable和各种XxxProcessors 实现了 Reactive Streams API，它允许Flowable其他兼容库使用 的实例，然后可以将任何实例包装Publisher到 a 中Flowable以使用它们并与它们组合丰富的运算符集。

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

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

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 Rscproject) 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 1 启发了 Reactive Streams 规范等其他来源，但无法利用它（必须保持兼容）。RxJava 2 是一个完全重写和独立的主版本，可以包含和使用 Reactive Streams 规范（甚至在内部扩展它，感谢Rsc项目）并且已经在 J​​ava 9 之前发布了将近一年。此外，它决定 v1 和 v2 都继续支持 Java 6 和许多 Android 运行时。因此，它不能直接利用 Java 9 现在提供的 Flow API，而只能通过桥接。其他基于 Reactive Streams 的库也需要和/或提供此类桥接器。

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.

RxJava 3 可能以 Java 9 Flow API 为目标，但这还没有决定，根据后续 Java 版本带来的特性（即值类型），我们可能在一年左右的时间内没有 v3。

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

到那时，有一个名为Reactive4JavaFlow的原型库，它确实实现了 Flow API，并在其上提供了 ReactiveX 风格的富流 API。

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

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

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.

Flow API 是一种互操作规范，而不是最终用户 API。通常，您不会直接使用它，而是将流传递给它的各种实现。当讨论 JEP 266 时，作者没有发现任何现有库的 API 足够好到 Flow API 的默认值（与丰富的java.util.Stream）。因此，决定用户现在必须依赖 3rd 方实现。

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.

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

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.

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

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

因此，一个更好的问题是，您现在应该开始使用基于 Flow API 的互操作还是坚持使用 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.

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

回答by madhead

At the beginning, there was Rx, version one. It was a language agnostic specification of reactive APIs that has implementations for Java, JavaScript, .NET. Then they improved it and we saw Rx 2. It has implementations for different languages as well. At the time of Rx 2 Spring team was working on Reactor— their own set of reactive APIs.

一开始，有 Rx，版本 1。它是一种与语言无关的响应式 API 规范，具有 Java、JavaScript、.NET 的实现。然后他们改进了它，我们看到了Rx 2。它也有不同语言的实现。在 Rx 2 的时候，Spring 团队正在研究Reactor——他们自己的一组反应式 API。

And then they all thought: why not make a joint effort and create one API to rule them all. That was how Reactive Commonswas set up. A joint research effort for building highly optimized reactive streams compliant operators. Current implementors include RxJava2 and Reactor.

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

At the same time JDK developers realized that reactive stuff is great and worth including in Java. As it is usual in Java world the de facto standard become de jure. Remeber Hibernate and JPA, Joda Time and Java 8 Date/Time API? So what JDK develpers did is extracting the very core of reactive APIs, the most basic part, and making it a standard. That is how j.u.c.Flowwas born.

与此同时，JDK 开发人员意识到响应式的东西很棒，值得包含在 Java 中。正如在 Java 世界中通常的那样，事实上的标准成为法律上的。还记得 Hibernate 和 JPA、Joda Time 和 Java 8 Date/Time API 吗？所以 JDK 开发者所做的就是提取响应式 API 的核心，最基本的部分，并使其成为标准。就这样j.u.c.Flow诞生了。

Technically, j.u.c.Flowis much more simpler, it consists only of four simple interfaces, while other libraries provide dozens of classes and hundreds of operators.

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

I hope, this answers the question "what is the difference between them".

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

Why would someone choose j.u.c.Flowover Rx? Well, because now it is a standard!

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

Currently JDK ships with only one implementation of j.u.c.Flow: HTTP/2 API. It is actually an incubating API. But in future we might expect support of it from Reactor, RxJava 2 as well as from other libraries, like reactive DB drivers or even FS IO.

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

回答by Piotr Wilkin

"What are the main differences between these two libraries?"

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

As you noted yourself, the Java 9 library is much more basic and basically serves as a general API for reactive streams instead of a full-fledged solution.

正如您自己指出的那样，Java 9 库更加基础，基本上用作响应式流的通用 API，而不是成熟的解决方案。

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

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

Well, for the same reason people use basic library constructs over libraries - one less dependency to manage. Also, due to the fact that the Flow API in Java 9 is more general, it is less constrained by the specific implementation.

嗯，出于同样的原因，人们在库上使用基本的库结构——少了一个需要管理的依赖。此外，由于 Java 9 中的 Flow API 更通用，因此受特定实现的约束较少。

回答by Naman

What are the main differences between these two libraries?

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

This mostly holds true as an informative comment(but too long to fit in), the JEP 266: More Concurrency Updatesresponsible for the introduction of the FlowAPI in Java9 states this in its description(emphasis mine) -

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

• Interfaces supporting the Reactive Streams publish-subscribe framework, nested within the new class Flow.

• Publishers produce items consumed by one or more Subscribers, each managed by a Subscription.

• Communication relies on a simple form of flow control (method Subscription.request, for communicating back pressure) that can be used to avoid resource management problems that may otherwise occur in "push" based systems. A utility class SubmissionPublisheris provided that developers can use to create custom components.

• These (very small) interfaces correspond to those defined with broad participation (from the Reactive Streams initiative) and support interoperability across a number of async systems running on JVMs.

• Nesting the interfaces within a class is a conservative policy allowing their use across various short-term and long-term possibilities. There are no plans to provide network- or I/O-based java.util.concurrentcomponents for distributed messaging, but it is possible that future JDK releases will include such APIs in other packages.

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

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

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

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

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

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

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

Looking at a wider prospect this is completely opinion based on factors like the type of application a client is developing and its usages of the framework.

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