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

Question

Il semble à chaque itération de Java pour les quelques dernières versions majeures, il y a en permanence de nouvelles façons de gérer des tâches simultanées.

En Java 9, nous avons l' API de Flux , qui ressemble à la Suspension de l'API de RxJava mais avec Java 9 est beaucoup plus simple dans un ensemble de classes et d'interfaces.

Java 9

A un Flow.Publisher, Flow.Subscriber, Flow.Processor, Flow.Subscription, et SubmissionPublisher, et c'est à ce sujet.

RxJava

A tout les paquets de l'API de Flux-comme pour 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 utiliser le Java 9 Flux de bibliothèque sur le beaucoup plus diversifiée RxJava bibliothèque ou vice-versa?

Answer 1

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

La Java 9 API de Flux n'est pas une bibliothèque autonome, mais une composante de la Java Standard Edition de la bibliothèque et se compose de 4 interfaces adoptée par le Réactif de Flux de spécification établie au début de 2015. En théorie, c'est l'intégration peut permettre JDK usages spécifiques, tels que l'incubation HttpClient, peut-être planifiées Async Connexion de Base de données dans les parties, et bien sûr, SubmissionPublisher.

RxJava est bibliothèque Java qui utilise la ReactiveX style de conception d'API pour fournir un ensemble complet d'opérateurs plus réactif (push) les flux de données. La Version 2, par Flowable et divers XxxProcessors, met en œuvre le Réactif API de Flux qui permet des instances de Flowable à être consommés par d'autres compatible avec les bibliothèques et, en retour, on peut encapsuler n'importe quel Publisher en Flowable à consommer ceux et composer de la richesse de l'ensemble des opérateurs avec eux.

Donc le Réactif API de Flux est le minimum spécification de l'interface et RxJava 2 est l'un de la mise en œuvre de ce sujet, ainsi que RxJava déclare un ensemble de méthodes supplémentaires pour former un riche et API fluent de son propre.

RxJava 1 a inspiré, entre autres sources, le Réactif de Flux de spécification, mais ne pouvait pas miser sur elle (devait rester compatible). RxJava 2, étant une réécriture complète et une autre version principale, pourrait embrasser et utiliser le Réactif de Flux de spécification (et même le développer en interne, grâce à la Rsc projet) et a été libéré près d'un an avant de Java 9. En outre, il a été décidé à la fois de v1 et v2 continue à soutenir la version 6 de Java et donc beaucoup de Android runtimes. Par conséquent, il ne pouvait pas tirer profit directement sur le Flux de l'API fournie aujourd'hui par Java 9 directement, mais seulement par l'intermédiaire d'un pont. Un tel pont est nécessaire et/ou fournies dans les autres Réactifs de Flux de données des bibliothèques de trop.

RxJava 3 mai cible Java 9 API de Flux, mais cela n'a pas été encore décidé, et selon quelles sont les caractéristiques de la subséquente versions de Java apporter (c'est à dire, des types de valeur), nous ne pouvons pas avoir la v3 de l'intérieur d'une année.

Jusqu'alors, il y a un prototype de bibliothèque appelée Reactive4JavaFlow qui implémente l'API de Flux et offre une ReactiveX style riche API fluent sur elle.

Pourquoi quelqu'un utiliser le Java 9 Flux de bibliothèque sur le beaucoup plus diversifiée RxJava bibliothèque ou vice-versa?

Le Flux de l'API est une spécification d'interopérabilité et pas un utilisateur de l'API. Normalement, vous ne devriez pas l'utiliser directement, mais pour transmettre des flux autour de diverses implémentations d'elle. Lorsque JEP 266 a été abordée, les auteurs n'ont trouvé aucune existant de la bibliothèque de l'API assez bon pour avoir quelque chose de défaut avec l'API de Flux (contrairement au riche, java.util.Stream). Par conséquent, il a été décidé que les utilisateurs devront appuyer sur la 3e partie des implémentations pour l'instant.

Vous devez attendre pour les réactifs bibliothèques à l'appui de l'API de Flux en mode natif, par le biais de leur propre pont de la mise en œuvre ou de nouvelles bibliothèques à être mis en œuvre.

Offrant un riche ensemble d'opérateurs sur le Flux de l'API est la seule raison pour laquelle une bibliothèque de la mettre en œuvre. Source de données fournisseurs (c'est à dire, les réactions des pilotes de base de données, réseau des bibliothèques) peuvent commencer à mettre en œuvre leurs propres données accesseurs via l'API de Flux et de s'appuyer sur la richesse des bibliothèques pour l'envelopper de ceux et de fournir de la transformation et de la coordination pour eux sans forcer tout le monde à mettre en œuvre toutes sortes de ces opérateurs.

Par conséquent, une meilleure question est, si vous commencez à utiliser l'API de Flux basé sur l'interopérabilité maintenant, ou s'en tenir à Réactif Flux?

Si vous avez besoin des solutions fiables et relativement peu de temps, je vous suggère de coller avec le Réactif de Flux de l'écosystème pour l'instant. Si vous avez beaucoup de temps ou si vous souhaitez explorer les choses, vous pourriez commencer à utiliser l'API de Flux.

Answer 2

Au début, il y avait Rx, version un. C'était une langue agnostique spécification de dérivés réactifs de l'Api qui a des implémentations de Java, JavaScript, .NET. Puis ils l'ont améliorée et nous avons vu Rx 2. Il a mises en oeuvre pour différentes langues. Au moment de Rx 2 Printemps équipe a travaillé sur des Réacteurs de leur propre ensemble de dérivés réactifs de l'Api.

Et puis ils ont tous pensé: pourquoi ne pas faire un effort commun et de créer une API pour les gouverner tous. C'est ainsi que Réactif de Communes a été mis en place. D'un commun effort de recherche pour la construction hautement optimisé réactif flux conforme opérateurs. Actuel des réalisateurs comprennent RxJava2 et le Réacteur.

Dans le même temps JDK les développeurs ont réalisé que réactif de choses est belle et vaut la peine, y compris en Java. Comme il est habituel dans le monde Java le standard de facto devenu de jure. Rappelez-vous Hibernate et JPA, Joda Temps et Java 8 Date/Heure API? Alors, quel JDK develpers n'est l'extraction de la base de dérivés réactifs de l'Api, la partie la plus fondamentale, et d'en faire un standard. C'est combien de j.u.c.Flow était né.

Techniquement, j.u.c.Flow est beaucoup plus simple, il ne se compose que de quatre interfaces simples, tandis que d'autres bibliothèques de fournir 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 de choisir j.u.c.Flow plus de Rx? Eh bien, parce que maintenant, c'est un standard!

Actuellement JDK fourni avec une seule mise en œuvre d' j.u.c.Flow: HTTP/2 API. C'est en fait une incubation de l'API. Mais à l'avenir, nous pourrions nous attendre à un soutien de la part du Réacteur, RxJava 2 ainsi que d'autres bibliothèques, comme réactif DB conducteurs ou même FS IO.

Answer 3

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

Comme vous l'avez souligné vous-même, la Java 9 bibliothèque est beaucoup plus simple et sert essentiellement comme un général de l'API pour les flux de réactif au lieu d'une véritable solution.

"Pourquoi voudrait-on utiliser le Java 9 Flux de bibliothèque sur le beaucoup plus diversifiée RxJava bibliothèque ou vice-versa?"

Eh bien, pour la même raison, les gens utilisent de base de la bibliothèque de constructions de plus de bibliothèques - un de moins de dépendance à gérer. Aussi, en raison du fait que le Flux d'API en Java 9 est plus général, il est moins contraint par la mise en œuvre spécifique.

Answer 4

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

La plupart du temps cela est vrai aussi instructif commentaire(mais trop longue), le JEP 266: Simultanéité Plus de Mises à jour de responsables de l'introduction de l' Flow API dans Java9 unis dans sa description(l'emphase est mienne) -

• Interfaces prenant le Réactif de Flux de publication-souscription cadre, imbriquée à l'intérieur de la nouvelle classe de Débit.

• Publishers produire des articles la consommation par un ou plusieurs Subscribers, chacun géré par un Subscription.

• La Communication s'appuie sur une forme simple de contrôle de flux (méthode Subscription.request, pour communiquer la pression de retour) qui peut être utilisé pour éviter les problèmes de gestion des ressources qui pourraient autrement se produire dans "push" pour les systèmes. Une classe utilitaire SubmissionPublisher est fourni que les développeurs peuvent utiliser pour créer des composants personnalisés.

• Ces (très les petits) interfaces correspondent à ceux définis avec une large participation (à partir du Réactif Flux de l'initiative) et l'appui de l'interopérabilité dans un certain nombre de async les systèmes fonctionnant sur des machines virtuelles.

• L'imbrication des interfaces au sein d'une classe est une politique conservatrice permettant leur utilisation dans divers à court terme et à long terme de possibilités. Il y ne prévoit pas de fournir réseau - ou-I/O-fondé java.util.concurrent les composants pour la distribution de messagerie, mais il est possible qu'à l'avenir les JDK les sorties d'inclure ces Api dans d'autres packages.

_{Pourquoi quelqu'un utiliser le Java 9 Flux de bibliothèque sur le beaucoup plus diversifiée RxJava bibliothèque ou vice-versa?}

À la recherche à une plus large perspective c'est complètement de l'opinion basée sur des facteurs comme le type de la demande d'un client est en développement et de ses usages dans le cadre.