Différence entre l’API RxJava et l’API Java 9 Flow

Question

Il semble qu'à chaque itération de Java), ces dernières versions majeures offrent systématiquement de nouvelles méthodes de gestion des tâches simultanées.

Dans Java 9, nous avons le Flow API qui ressemble au Flowable API de RxJava mais avec Java = 9 a un ensemble beaucoup plus simple de classes et d'interfaces.

Java 9

A un Flow.Publisher, Flow.Subscriber, Flow.Processor, Flow.Subscription, et SubmissionPublisher, et c'est à peu près tout.

RxJava

A tout paquets sur Flow API - comme les classes, c'est-à-dire io.reactivex.flowables, io.reactivex.subscribers, io.reactivex.processors, io.reactivex.observers, et io.reactivex.observables qui semblent faire quelque chose de similaire.

Quelles sont les principales différences entre ces deux bibliothèques? Pourquoi quelqu'un utiliserait-il la bibliothèque Java 9 Flow par rapport à la bibliothèque beaucoup plus diverse de RxJava ou vice versa?)

akarnokd · Accepted Answer

Quelles sont les principales différences entre ces deux bibliothèques?

L’API Flow Java 9) n’est pas une bibliothèque autonome, mais un composant de la bibliothèque Java Standard Edition) et se compose de 4 interfaces adoptées à partir de la Reactive Streams spécification établie au début de 2015. En théorie, son inclusion peut permettre des utilisations spécifiques dans le JDK, telles que l'incubation de HttpClient, peut-être la connexion planifiée à la base de données asynchrone par parties, et bien sûr SubmissionPublisher.

RxJava est une bibliothèque Java qui utilise la conception de l'API de style ReactiveX pour fournir un riche ensemble d'opérateurs sur des flux de données réactifs (Push). Version 2, via Flowable et divers XxxProcessors, implémente l’API de Reactive Streams qui permet aux instances de Flowable d’être consommées par d’autres bibliothèques compatibles et permet ensuite d’envelopper n’importe quel Publisher dans un Flowable de les consommer et composer le riche ensemble d'opérateurs avec eux.

Ainsi, l’API Reactive Streams est la spécification d’interface minimale et RxJava 2 en est une implémentation , plus RxJava déclare un grand ensemble de méthodes supplémentaires pour former une API riche et fluide.

RxJava 1 a inspiré, entre autres sources, la spécification Reactive Streams mais n’a pas pu en tirer parti (elle devait rester compatible). RxJava 2, étant une réécriture complète et une version principale séparée, pourrait adopter et utiliser la spécification Reactive Streams (et même la développer en interne, grâce au projet Rsc ) et a été publié presque un an auparavant. Java 9. De plus, il a été décidé que les versions v1 et v2 continueraient de prendre en charge Java 6 et donc beaucoup de Android Par conséquent, il ne pouvait pas capitaliser directement sur l’API Flow fournie à présent par Java 9 directement mais uniquement via un pont = pont . Ce pont est requis par et/ou fourni dans d'autres bibliothèques basées sur les flux réactifs aussi.

RxJava 3 peut cibler le Java 9 Flow API, mais cela n’a pas encore été décidé et, en fonction des fonctionnalités, les Java suivantes apportent (par exemple, les types de valeur ), nous ne pouvons pas avoir v3 dans un an ou plus.

Jusque-là, il existe un prototype de bibliothèque appelé Reactive4JavaFlow qui implémente l’API Flow et offre une API riche, fluide et de style ReactiveX.

Pourquoi quelqu'un utiliserait-il la bibliothèque Java 9 Flow par rapport à la bibliothèque beaucoup plus diverse de RxJava ou vice versa?)

L'API Flow est une spécification d'interopérabilité et non une API d'utilisateur final. Normalement, vous ne l'utiliseriez pas directement mais transmettriez les flux à différentes implémentations. Lors de l’examen du JEP 266, les auteurs n’ont trouvé l’API d’une bibliothèque existante suffisante pour présenter un défaut avec l’API Flow (contrairement à la riche Java.util.Stream). Par conséquent, il a été décidé que les utilisateurs devront s’appuyer sur des implémentations tierces pour le moment.

Vous devez attendre que les bibliothèques réactives existantes prennent en charge l’API Flow de manière native, via leur propre implémentation de pont ou les nouvelles bibliothèques à implémenter.

Fournir un ensemble complet d'opérateurs sur l'API Flow est la seule raison pour laquelle une bibliothèque l'implémenterait. Les fournisseurs de sources de données (pilotes de base de données réactifs, bibliothèques de réseau, par exemple) peuvent commencer à implémenter leurs propres accesseurs de données via l’API Flow et s’appuyer sur les bibliothèques riches pour les encapsuler et leur fournir transformation et coordination sans forcer tout le monde à implémenter toutes sortes de ces opérateurs. .

Par conséquent, une meilleure question est la suivante: devez-vous commencer à utiliser l'interopérabilité basée sur l'API Flow ou vous en tenir aux flux réactifs?

Si vous avez besoin de solutions fiables et efficaces relativement rapidement, je vous suggère de vous en tenir à l'écosystème Reactive Streams pour le moment. Si vous avez suffisamment de temps ou si vous souhaitez explorer certaines choses, vous pouvez commencer à utiliser l’API Flow.

madhead · Answer

Au début, il y avait Rx, version un. C'était une spécification agnostique de langage d'API réactives qui a des implémentations pour Java, JavaScript, .NET. Ensuite, ils l’ont amélioré et nous avons vu Rx 2 . Il a également des implémentations pour différentes langues. Au moment de Rx 2, l’équipe Spring travaillait sur Reactor - son propre ensemble d’API réactives.

Et ensuite, ils se sont tous demandé: pourquoi ne pas faire un effort commun et créer une API unique pour tous les gouverner? C'est ainsi que Reactive Commons a été mis en place. Un effort de recherche commun pour la construction d’opérateurs conformes aux flux réactifs hautement optimisés. Les implémenteurs actuels incluent RxJava2 et Reactor.

Dans le même temps, les développeurs de JDK ont compris que les éléments réactifs sont intéressants et qu'il vaut la peine de les inclure en Java. Comme il est habituel dans Java monde, le standard de facto devient de jure. Rappelez-vous Hibernate et JPA, Joda Time et Java 8 API Date/Heure? Alors quoi? Les développeurs de JDK ont extrait le noyau même des API réactives, la partie la plus élémentaire, et en ont fait une norme, c'est ainsi que j.u.c.Flow Est né.

Techniquement, j.u.c.Flow Est beaucoup plus simple, il se compose uniquement de quatre interfaces simples , tandis que d'autres bibliothèques fournissent des dizaines de classes et des centaines d'opérateurs.

J'espère que cela répond à la question "quelle est la différence entre eux".

Pourquoi quelqu'un choisirait-il j.u.c.Flow Plutôt que Rx? Eh bien, parce que maintenant c'est un standard!

Actuellement, JDK est livré avec une seule implémentation de j.u.c.Flow: HTTP/2 API . C'est en fait une API en incubation. Mais à l’avenir, on pourrait s’attendre à ce qu’il soit pris en charge par Reactor, RxJava 2 ainsi que par d’autres bibliothèques, telles que des pilotes de base de données réactifs ou même FS IO.

Piotr Wilkin · Answer

"Quelles sont les principales différences entre ces deux bibliothèques?"

Comme vous l'avez constaté vous-même, la bibliothèque Java 9 est beaucoup plus basique et sert essentiellement d'API générale pour les flux réactifs au lieu d'une solution à part entière.

"Pourquoi quelqu'un utiliserait-il la bibliothèque Java 9 Flow par rapport à la bibliothèque beaucoup plus diverse de RxJava ou vice versa?"

Eh bien, pour la même raison, les gens utilisent des constructions de bibliothèque de base par rapport aux bibliothèques: une dépendance de moins à gérer. De plus, du fait que l’API Flow de Java 9 est plus général, il est moins contraint par l’implémentation spécifique.

Naman · Answer

Quelles sont les principales différences entre ces deux bibliothèques?

Ceci est généralement valable en tant que commentaire informatif (mais trop long à intégrer), le JEP 266: autres mises à jour simultanées responsable de l'introduction de l'API Flow en Java9 l'indique dans sa description (emphase le mien) -

Interfaces supportant le cadre de publication-abonnement Flux réactifs, imbriquées dans la nouvelle classe Flow .
Publishers produisent des éléments consommés par un ou plusieurs Subscribers, chacun géré par un Subscription.
La communication repose sur une forme simple de contrôle de flux (méthode Subscription.request, Pour communiquer la contre-pression), qui peut être utilisée pour éviter les problèmes de gestion des ressources qui pourraient autrement se produire dans les systèmes "Push". Une classe d'utilitaires SubmissionPublisher est fournie et peut être utilisée par les développeurs pour créer des composants personnalisés.
Ces (très petites) interfaces correspondent à celles définies avec une large participation (de l'initiative Reactive Streams) et soutiennent l'interopérabilité entre plusieurs systèmes asynchrones exécutés sur des machines virtuelles.
L'imbrication des interfaces dans une classe est une politique conservatrice permettant leur utilisation dans diverses possibilités à court et à long terme . Il n'est pas prévu de fournir des composants Java.util.concurrent Basés sur le réseau ou sur les E/S pour la messagerie distribuée, mais il est possible que les futures versions du JDK incluent de telles API dans d'autres packages.

_{Pourquoi quelqu'un utiliserait-il la bibliothèque Java 9 Flow par rapport à la bibliothèque beaucoup plus diverse de RxJava ou vice versa?)}

Dans une perspective plus large, il s’agit d’un avis entièrement basé sur des facteurs tels que le type d’application qu’un client développe et ses utilisations du cadre.