RxJava APIとJava 9 Flow APIの違い

Question

過去数回のメジャーリリースでJavaを繰り返すたびに、並行タスクを管理するための一貫した新しい方法があるようです。

Java 9には、RxJavaの Flow API に似た Flow API がありますが、Java 9の方がはるかにシンプルですクラスとインターフェースのセット。

Java 9

Flow.Publisher、Flow.Subscriber、Flow.Processor、Flow.Subscription、およびSubmissionPublisherがあり、それで十分です。

RxJava

全体packages of Flow API -likeクラス、つまりio.reactivex.flowables、io.reactivex.subscribers、io.reactivex.processors、io.reactivex.observers、およびio.reactivex.observablesこれは似たようなことをしているようです。

これら2つのライブラリの主な違いは何ですか？なぜ誰かがJava 9 Flowライブラリをはるかに多様なRxJavaライブラリで使用するのでしょうか？

akarnokd · Accepted Answer

これら2つのライブラリの主な違いは何ですか？

Java 9 Flow APIはスタンドアロンライブラリではなく、Java Standard Editionライブラリのコンポーネントであり、確立された Reactive Streams 仕様から採用された4つのインターフェイスで構成されます理論的には、インクルードにより、HttpClientのインキュベーション、計画されている非同期データベース接続など、JDK内での特定の使用が可能になります。もちろんSubmissionPublisher。

RxJavaはJavaライブラリであり、ReactiveXスタイルのAPIデザインを使用して、リアクティブ（プッシュ）データフローに対して豊富な演算子セットを提供します。バージョン2は、FlowableおよびさまざまなXxxProcessorsを介して、Flowableのインスタンスを他の互換性のあるライブラリで使用できるようにするReactive Streams APIを実装し、任意のPublisher Flowableに変換して、それらを消費し、豊富な演算子セットを作成します。

したがって、Reactive Streams APIは最小限のインターフェース仕様であり、RxJava 2は1つ実装それに加えて、RxJavaは独自のリッチで流APIなAPIを形成するための追加のメソッドの大きなセットを宣言します。

RxJava 1は、とりわけReactive Streams仕様に影響を与えましたが、それを活用できませんでした（互換性を維持する必要がありました）。 RxJava 2は完全に書き換えられ、別のメインバージョンであり、Reactive Streams仕様を採用および使用することができ（さらに、 Rsc プロジェクトのおかげで内部的に拡張することもできます）、ほぼ1年前にリリースされましたJava 9.さらに、v1とv2の両方がJava 6をサポートし、したがって多くのAndroidランタイムをサポートし続けることが決定されました。したがって、現在Java 9によって直接提供されているFlow APIを直接利用することはできませんでしたが、 bridge を介してのみ利用できました。このようなブリッジは、他のReactive Streamsベースのライブラリでも必要であり、および/または提供されます。

RxJava 3はJava 9 Flow APIをターゲットとする場合がありますが、これはまだ決定されておらず、後続のJavaバージョンがもたらす機能（値タイプ）に応じて、 1年以内のv3。

それまでは、Flow APIを実装し、ReactiveXスタイルのリッチで流richなAPIを提供する Reactive4JavaFlow というプロトタイプライブラリがあります。

なぜ誰かがJava 9 Flowライブラリをはるかに多様なRxJavaライブラリで使用するのでしょうか？

Flow APIは相互運用仕様であり、エンドユーザーAPIではありません。通常、直接使用するのではなく、フローをさまざまな実装に渡します。 JEP 266が議論されたとき、著者は、既存のライブラリのAPIがFlow APIでデフォルトを設定するのに十分であるとは思いませんでした（リッチJava.util.Streamとは異なります）。したがって、ユーザーは今のところサードパーティの実装に依存する必要があると判断されました。

既存のリアクティブライブラリが独自のブリッジ実装または新しいライブラリの実装を通じてFlow APIをネイティブにサポートするのを待つ必要があります。

Flow APIを介して豊富な演算子セットを提供することは、ライブラリがそれを実装する唯一の理由です。データソースベンダー（つまり、リアクティブデータベースドライバー、ネットワークライブラリ）は、Flow APIを介して独自のデータアクセサーの実装を開始し、リッチライブラリに依存してそれらをラップし、すべての種類の演算子をすべてのユーザーに強制せずに変換と調整を提供します。

したがって、より良い質問は、Flow APIベースの相互運用を今すぐ使用するか、Reactive Streamsにこだわるかです。

比較的早く実用的で信頼性の高いソリューションが必要な場合は、現時点ではReactive Streamsエコシステムを使用することをお勧めします。十分な時間がある場合、または物事を調べたい場合は、Flow APIの使用を開始できます。

madhead · Answer

最初はRxバージョン1がありました。これは、Java、JavaScript、.NETの実装を備えたリアクティブAPIの言語に依存しない仕様でした。その後、彼らはそれを改善し、 Rx 2 を見ました。さまざまな言語の実装もあります。 Rx 2の時点で、Springチームは Reactor —独自のリアクティブAPIのセットに取り組んでいました。

そして、彼らはみんな考えました：一緒に努力して、すべてを支配する1つのAPIを作成してみませんか。それが Reactive Commons の設定方法でした。高度に最適化されたリアクティブストリームに準拠したオペレーターを構築するための共同研究。現在の実装者には、RxJava2とReactorが含まれます。

同時に、JDK開発者は、リアクティブなものはJavaに含める価値があり、価値があることを認識しました。 Javaの世界ではよくあることですが、事実上の標準はデジュールになります。 HibernateとJPA、Joda TimeとJava 8 Date/Time APIを覚えていますか？したがって、JDK開発者が行ったのは、最も基本的な部分であるリアクティブAPIのコアを抽出し、それを標準にすることです。それがj.u.c.Flowが生まれた方法です。

技術的には、j.u.c.Flowははるかに単純で、 4つの単純なインターフェイスのみで構成されますが、他のライブラリは数十のクラスと数百の演算子を提供します。

これが「両者の違いは何か」という質問の答えになることを願っています。

誰かがRxよりもj.u.c.Flowを選択するのはなぜですか？さて、今では標準だからです！

現在、JDKにはj.u.c.Flowの実装が1つだけ付属しています： HTTP/2 API 。これは、実際にはインキュベーションAPIです。しかし、将来的には、Reactor、RxJava 2、およびリアクティブDBドライバーやFS IOなどの他のライブラリーからのサポートが期待されるかもしれません。

Piotr Wilkin · Answer

「これら2つのライブラリの主な違いは何ですか？」

既に述べたように、Java 9ライブラリははるかに基本的であり、基本的には本格的なソリューションではなく、リアクティブストリームの一般的なAPIとして機能します。

「はるかに多様なRxJavaライブラリでJava 9 Flowライブラリを使用するのはなぜですか？」

まあ、同じ理由で、人々はライブラリよりも基本的なライブラリ構造を使用します-管理する依存性が1つ少なくなります。また、Java 9のFlow APIはより一般的であるという事実により、特定の実装による制約が少なくなります。

Naman · Answer

これら2つのライブラリの主な違いは何ですか？

これはほとんどの場合、有益なコメント（ただし長すぎて収まらない）、 JEP 266：More Concurrency Updates Java9でFlow APIの導入を担当していることは、その説明（強調マイン）でこれを述べています-

Reactive Streamsパブリッシュ/サブスクライブフレームワークをサポートするインターフェイス。新しいクラスFlow内にネストされています。
Publishersは、1つ以上のSubscribersによって消費されるアイテムを生成し、それぞれSubscriptionによって管理されます。
通信は、「プッシュ」ベースのシステムで発生する可能性のあるリソース管理の問題を回避するために使用できる単純な形式のフロー制御（メソッドSubscription.request、背圧の通信）に依存しています。開発者がカスタムコンポーネントの作成に使用できるユーティリティクラスSubmissionPublisherが提供されます。
これらの（非常に小さい）インターフェースは（Reactive Streamsイニシアチブからの）幅広い参加で定義されたインターフェースに対応し、JVMで実行されている多くの非同期システムでの相互運用性をサポートします。
クラス内のインターフェースのネストは、さまざまな短期的および長期的な可能性にわたって使用できるようにする保守的なポリシーです。分散メッセージング用のネットワークベースまたはI/OベースのJava.util.concurrentコンポーネントを提供する予定はありませんただし、将来のJDKリリースでは、このようなAPIが他のパッケージに含まれる可能性があります。

_{なぜ誰かがJava 9 Flowライブラリをはるかに多様なRxJavaライブラリで使用するのでしょうか？}

より広い展望を見ると、これは完全に、クライアントが開発しているアプリケーションのタイプやフレームワークの使用法などの要因に基づいた意見です。