Unterschied zwischen RxJava API und der Java 9 Flow API

Lesezeit: 7 Minuten

Benutzer-Avatar
Dovmo

Es scheint, dass es bei jeder Iteration von Java für die letzten paar Hauptversionen ständig neue Möglichkeiten gibt, gleichzeitige Aufgaben zu verwalten.

In Java 9 haben wir die Flow-API was dem ähnelt Fließfähige API von RxJava, aber mit Java 9 hat es einen viel einfacheren Satz von Klassen und Schnittstellen.

Java 9

Hat ein Flow.Publisher, Flow.Subscriber, Flow.Processor, Flow.Subscriptionund SubmissionPublisherund das war es auch schon.

RxJava

Hat ganz Pakete von Flow-API-ähnliche Klassen, dh io.reactivex.flowables, io.reactivex.subscribers, io.reactivex.processors, io.reactivex.observersund io.reactivex.observables die scheinen etwas ähnliches zu tun.

Was sind die Hauptunterschiede zwischen diesen beiden Bibliotheken? Warum sollte jemand die Java 9 Flow-Bibliothek gegenüber der viel vielfältigeren RxJava-Bibliothek verwenden oder umgekehrt?

Benutzer-Avatar
akarnokd

Was sind die Hauptunterschiede zwischen diesen beiden Bibliotheken?

Die Java 9 Flow API ist keine eigenständige Bibliothek, sondern eine Komponente der Java Standard Edition-Bibliothek und besteht aus 4 Schnittstellen, die von der übernommen wurden Reaktive Ströme Spezifikation, die Anfang 2015 erstellt wurde. Theoretisch kann ihre Aufnahme in-JDK spezifische Verwendungen ermöglichen, wie z. B. den inkubierenden HttpClient, vielleicht die geplante Async Database Connection in Teilen und natürlich SubmissionPublisher.

RxJava ist eine Java-Bibliothek, die das API-Design im ReactiveX-Stil verwendet, um eine Vielzahl von Operatoren für reaktive (Push-)Datenflüsse bereitzustellen. Version 2, durch Flowable und verschiedene XxxProcessors, implementiert die Reactive Streams-API, die Instanzen von zulässt Flowable von anderen kompatiblen Bibliotheken konsumiert werden und man kann wiederum beliebige umschließen Publisher in ein Flowable um diese zu konsumieren und mit ihnen den reichhaltigen Satz von Operatoren zusammenzustellen.

Die Reactive Streams API ist also die Minimale Schnittstellenspezifikation und RxJava 2 ist eins Implementierung davon, plus RxJava deklariert eine große Menge zusätzlicher Methoden, um eine eigene reichhaltige und fließende API zu bilden.

RxJava 1 inspirierte unter anderem die Reactive Streams-Spezifikation, konnte daraus aber keinen Kapital schlagen (muss kompatibel bleiben). RxJava 2, das eine vollständige Neufassung und eine separate Hauptversion ist, könnte die Reactive Streams-Spezifikation umfassen und verwenden (und dank der Rsc Project) und wurde fast ein Jahr vor Java 9 veröffentlicht. Außerdem wurde entschieden, dass sowohl v1 als auch v2 weiterhin Java 6 und damit viele Android-Laufzeiten unterstützen. Daher konnte es nicht direkt von der jetzt von Java 9 bereitgestellten Flow-API profitieren, sondern nur über a Brücke. Eine solche Bridge wird auch von anderen auf Reactive Streams basierenden Bibliotheken benötigt und/oder bereitgestellt.

RxJava 3 zielt möglicherweise auf die Java 9 Flow API ab, aber dies wurde noch nicht entschieden, und je nachdem, welche Funktionen die nachfolgenden Java-Versionen bringen (dh Werttypen), haben wir v3 möglicherweise nicht innerhalb eines Jahres oder so.

Bis dahin gibt es eine Prototypbibliothek namens Reactive4JavaFlow das die Flow-API implementiert und darüber eine reichhaltige Fluent-API im ReactiveX-Stil bietet.

Warum sollte jemand die Java 9 Flow-Bibliothek gegenüber der viel vielfältigeren RxJava-Bibliothek verwenden oder umgekehrt?

Die Flow-API ist eine Interoperationsspezifikation und keine Endbenutzer-API. Normalerweise würden Sie es nicht direkt verwenden, sondern um Flows an verschiedene Implementierungen davon weiterzuleiten. Als JEP 266 besprochen wurde, fanden die Autoren keine vorhandene Bibliotheks-API gut genug, um etwas Standardmäßiges mit der Flow-API zu haben (im Gegensatz zu den Rich java.util.Stream). Daher wurde entschieden, dass sich die Benutzer vorerst auf Implementierungen von Drittanbietern verlassen müssen.

Sie müssen warten, bis vorhandene reaktive Bibliotheken die Flow-API nativ unterstützen, durch ihre eigene Bridge-Implementierung oder neue zu implementierende Bibliotheken.

Das Bereitstellen einer Vielzahl von Operatoren über die Flow-API ist nur der Grund, warum eine Bibliothek sie implementieren würde. Anbieter von Datenquellen (z. B. reaktive Datenbanktreiber, Netzwerkbibliotheken) können mit der Implementierung ihrer eigenen Datenzugriffsmethoden über die Flow-API beginnen und sich auf die umfangreichen Bibliotheken verlassen, um diese zu verpacken und die Transformation und Koordination für sie bereitzustellen, ohne dass jeder gezwungen wird, alle möglichen dieser Operatoren zu implementieren .

Daher ist eine bessere Frage, sollten Sie jetzt mit der Verwendung der Flow-API-basierten Interoperation beginnen oder bei Reactive Streams bleiben?

Wenn Sie relativ bald funktionierende und zuverlässige Lösungen benötigen, schlage ich vor, dass Sie vorerst beim Reactive Streams-Ökosystem bleiben. Wenn Sie viel Zeit haben oder Dinge erkunden möchten, können Sie mit der Verwendung der Flow-API beginnen.

Benutzer-Avatar
verrückter Kopf

Am Anfang war Rx, Version eins. Es war eine sprachunabhängige Spezifikation reaktiver APIs mit Implementierungen für Java, JavaScript und .NET. Dann haben sie es verbessert und wir haben es gesehen Empfang 2. Es hat auch Implementierungen für verschiedene Sprachen. Zum Zeitpunkt von Rx 2 arbeitete das Spring-Team daran Reaktor — ihre eigenen reaktiven APIs.

Und dann dachten alle: Warum nicht eine gemeinsame Anstrengung unternehmen und eine API schaffen, die sie alle beherrscht. So war es Reaktive Commons wurde eingerichtet. Eine gemeinsame Forschungsanstrengung zum Aufbau hochoptimierter reaktiver Streams-konformer Operatoren. Aktuelle Implementierer sind RxJava2 und Reactor.

Gleichzeitig erkannten JDK-Entwickler, dass reaktives Zeug großartig und es wert ist, in Java aufgenommen zu werden. Wie es in der Java-Welt üblich ist, wird der De-facto-Standard de jure. Erinnern Sie sich an Hibernate und JPA, Joda Time und Java 8 Date/Time API? Was die JDK-Entwickler also getan haben, ist, den Kern reaktiver APIs, den grundlegendsten Teil, zu extrahieren und ihn zu einem Standard zu machen. Das ist wie j.u.c.Flow wurde geboren.

Technisch, j.u.c.Flow ist viel einfacher, es besteht nur aus vier einfache Schnittstellenwährend andere Bibliotheken Dutzende von Klassen und Hunderte von Operatoren bereitstellen.

Ich hoffe, dies beantwortet die Frage “was ist der Unterschied zwischen ihnen”.

Warum sollte jemand wählen j.u.c.Flow über Rx? Nun, weil es jetzt ein Standard ist!

Derzeit wird JDK mit nur einer Implementierung von ausgeliefert j.u.c.Flow: HTTP/2-API. Es ist eigentlich eine Inkubations-API. Aber in Zukunft könnten wir Unterstützung von Reactor, RxJava 2 sowie von anderen Bibliotheken wie reaktiven DB-Treibern oder sogar FS IO erwarten.

  • Sie hatten ein paar Ereignisse zusammengeführt. Die Reactive Streams-Initiative war der Sammelpunkt, kurz nachdem RxJava 0.x stabil genug geworden war. Die Reactive Streams Commons kamen Anfang 2016 mit dem Ziel, das Sie richtig angegeben haben.

    – akarnokd

    17. November 2017 um 19:37 Uhr

“Was sind die Hauptunterschiede zwischen diesen beiden Bibliotheken?”

Wie Sie selbst bemerkt haben, ist die Java 9-Bibliothek viel einfacher und dient im Grunde als allgemeine API für reaktive Streams und nicht als vollwertige Lösung.

“Warum sollte jemand die Java 9 Flow-Bibliothek gegenüber der viel vielfältigeren RxJava-Bibliothek verwenden oder umgekehrt?”

Nun, aus dem gleichen Grund verwenden die Leute grundlegende Bibliothekskonstrukte gegenüber Bibliotheken – eine Abhängigkeit weniger, die verwaltet werden muss. Aufgrund der Tatsache, dass die Flow-API in Java 9 allgemeiner ist, ist sie außerdem weniger durch die spezifische Implementierung eingeschränkt.

Was sind die Hauptunterschiede zwischen diesen beiden Bibliotheken?

Dies gilt meistens als informativer Kommentar (aber zu lang, um hineinzupassen), der JEP 266: Mehr Concurrency-Updates verantwortlich für die Einführung der Flow API in Java9 gibt dies in seiner Beschreibung an (Hervorhebung von mir) –

  • Schnittstellen, die das unterstützen Reactive Streams Publish-Subscribe-Frameworkverschachtelt in der neuen Klasse Fließen.

  • Publishers produzieren Gegenstände, die von einem oder mehreren konsumiert werden Subscribers, jeweils verwaltet von a Subscription.

  • Die Kommunikation beruht auf einer einfachen Form der Flusskontrolle (method
    Subscription.request, zum Kommunizieren des Gegendrucks), die verwendet werden können, um Ressourcenverwaltungsprobleme zu vermeiden, die andernfalls in “Push”-basierten Systemen auftreten können. Eine Gebrauchsklasse SubmissionPublisher wird bereitgestellt, die Entwickler verwenden können, um benutzerdefinierte Komponenten zu erstellen.

  • Diese (sehr kleinen) Schnittstellen entsprechen denen, die unter breiter Beteiligung (von der Reactive Streams-Initiative) definiert wurden, und unterstützen die Interoperabilität über eine Reihe von asynchronen Systemen, die auf JVMs laufen.

  • Das Verschachteln der Schnittstellen innerhalb einer Klasse ist a konservative Politik, die ihren Einsatz über verschiedene kurz- und langfristige Möglichkeiten hinweg ermöglicht. Es ist nicht geplant, netzwerk- oder I/O-basiert bereitzustellen java.util.concurrent
    Komponenten für verteiltes Messaging, Es ist jedoch möglich, dass zukünftige JDK-Versionen solche APIs in anderen Paketen enthalten.

Warum sollte jemand die Java 9 Flow-Bibliothek gegenüber der viel vielfältigeren RxJava-Bibliothek verwenden oder umgekehrt?

Aus allgemeiner Sicht ist dies eine Meinung, die auf Faktoren wie der Art der Anwendung, die ein Kunde entwickelt, und seiner Verwendung des Frameworks basiert.

1179270cookie-checkUnterschied zwischen RxJava API und der Java 9 Flow API

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy