Разница между RxJava API и Java 9 Flow API

кажется, что на каждой итерации Java для последних нескольких основных выпусков есть последовательно новые способы управления параллельными задачами.

в Java 9, у нас есть API потока который напоминает Flowable API RxJava, но с Java 9 имеет гораздо более простой набор классов и интерфейсов.

Java 9

есть Flow.Publisher, Flow.Subscriber, Flow.Processor, Flow.Subscription и SubmissionPublisher, а вот про он.

RxJava

все пакетов of API потока - подобные классы, т. е. io.reactivex.flowables, io.reactivex.subscribers, io.reactivex.processors, io.reactivex.observers и io.reactivex.observables которые, кажется, делают что-то подобное.

каковы основные различия между этими двумя библиотеками? Зачем кому-то использовать библиотеку потоков Java 9 над гораздо более разнообразной библиотекой RxJava или наоборот?

4 ответов


каковы основные различия между этими двумя библиотеками?

Java 9 Flow API не является автономной библиотекой, но является компонентом библиотеки Java Standard Edition и состоит из 4 интерфейсов, принятых из Реактивные Потоки спецификация установленная в начале 2015. Теоретически, это включение может включить в-JDK определенные использования, такие как инкубационный HttpClient, возможно, запланированное асинхронное соединение с базой данных по частям и, конечно SubmissionPublisher.

RxJava-это библиотека Java, которая использует дизайн API стиля ReactiveX для предоставления богатого набора операторов над реактивными (push) потоками данных. Версия 2, через Flowable различные XxxProcessors, реализует API реактивных потоков, который позволяет экземплярам Flowable потребляется другими совместимыми библиотеками и, в свою очередь, можно обернуть любой Publisher на Flowable потреблять их и составлять с ними богатый набор операторов.

таким образом, API реактивных потоков минимальная спецификация интерфейса и RxJava 2-один реализация of it, plus RxJava объявляет большой набор дополнительных методов для формирования собственного богатого и свободного API.

RxJava 1 вдохновил, среди других источников, спецификацию реактивных потоков, но не смог извлечь из нее выгоду (должен был оставаться совместимым). RxJava 2, будучи полной перезаписью и отдельной основной версией, может охватывать и использовать спецификацию реактивных потоков (и даже расширять это внутренне, благодаря Rsc project) и был выпущен почти за год до Java 9. Кроме того, было решено, что v1 и v2 поддерживают Java 6 и, следовательно, много времени выполнения Android. Поэтому он не мог извлечь выгоду непосредственно из API потока, предоставляемого теперь Java 9 напрямую, но только через мост. Такой мост требуется и / или предоставляется в других библиотеках на основе реактивных потоков.

RxJava 3 может нацелиться на API потока Java 9 но это еще не решено, и в зависимости от того, какие функции приносят последующие версии Java (т. е. типы значений), у нас может не быть v3 в течение года или около того.

до тех пор существует прототип библиотеки под названием Reactive4JavaFlow который реализует API потока и предлагает ReactiveX style rich fluent API над ним.

почему кто-то использует библиотеку потока Java 9 над гораздо более разнообразной библиотекой RxJava или вице наоборот?

API потока-это спецификация взаимодействия, а не API конечного пользователя. Обычно вы не используете его напрямую, а передаете потоки в различные его реализации. Когда обсуждался JEP 266, авторы не нашли API существующей библиотеки достаточно хорошим, чтобы иметь что-то по умолчанию с API потока (в отличие от rich java.util.Stream). Поэтому было решено, что пока пользователям придется полагаться на сторонние реализации.

вы должны ждать существующие реактивные библиотеки для поддержки API потока изначально, через их собственную реализацию моста или новые библиотеки, которые будут реализованы.

предоставление богатого набора операторов по API потока является единственной причиной, по которой библиотека будет его реализовывать. Поставщики источников данных (т. е. драйверы реактивных баз данных, сетевые библиотеки) могут начать реализовывать свои собственные методы доступа к данным через API потока и полагаться на богатые библиотеки, чтобы обернуть их и обеспечить преобразование и координацию для них не заставляя всех реализовывать всевозможные эти операторы.

следовательно, лучший вопрос заключается в том, должны ли вы начать использовать взаимодействие на основе API потока сейчас или придерживаться реактивных потоков?

Если вам нужны рабочие и надежные решения относительно скоро,я предлагаю вам придерживаться экосистемы реактивных потоков. Если у вас есть много времени или вы хотите изучить вещи, вы можете начать использовать Flow API.


в начале был Rx, версия один. Это была языковая агностическая спецификация реактивных API, которая имеет реализации для Java, JavaScript,.Сеть. Затем они улучшили его, и мы увидели Rx 2. Он имеет реализации для различных языков, а также. В то время команда RX 2 Spring работала над реактор - их собственный набор реактивных API.

и тогда они все подумали: почему бы не сделать совместные усилия и создать один API, чтобы управлять ими всеми. Что было как Реактивные Общие была создана. Совместные усилия исследования для построения высоко оптимизированных операторов, совместимых с реактивными потоками. Текущие исполнители включают RxJava2 и реактор.

в то же время разработчики JDK поняли, что реактивный материал велик и стоит включить в Java. Как обычно в мире Java, де-факто стандарт становится де-юре. Remeber Hibernate и JPA, Joda Time и Java 8 Дата/Время API? Так что JDK develpers сделал, это извлечение самого ядра реактивный API, самая основная часть, и делает его стандартом. Вот как!-Родился -0-->.

технически j.u.c.Flow гораздо проще, он состоит только из четыре простых интерфейсов, в то время как другие библиотеки предоставляют десятки классов и сотни операторов.

Я надеюсь, это отвечает на вопрос "в чем разница между ними".

зачем кому-то выбрать j.u.c.Flow над Rx? Ну, потому что теперь это стандарт!

В настоящее время JDK поставляется только с одной реализацией j.u.c.Flow: HTTP/2 API. На самом деле это инкубационный API. Но в будущем мы можем ожидать его поддержки от Reactor, RxJava 2, а также от других библиотек, таких как реактивные драйверы БД или даже FS IO.


"каковы основные различия между этими двумя библиотеками?"

Как вы сами отметили, библиотека Java 9 намного более базовая и в основном служит общим API для реактивных потоков вместо полноценного решения.

" зачем кому-то использовать библиотеку потоков Java 9 над гораздо более разнообразной библиотекой RxJava или наоборот?"

ну, по той же причине люди используют базовые библиотечные конструкции над библиотеками - одной зависимостью меньше для управления. Кроме того, из-за того, что API потока в Java 9 является более общим, он менее ограничен конкретной реализацией.


каковы основные различия между этими двумя библиотеками?

это в основном верно как информативный комментарий (но слишком долго, чтобы вписаться),JEP 266: больше обновлений параллелизма ответственный за введение Flow API в Java9 заявляет это в своем описании (акцент мой) -

  • интерфейсы обслуживания реактивные потоки опубликовать-подписаться рамки, вложенный в новый класс поток.

  • Publisher детали продукции с потребляется одним или несколькими Subscribers, каждый управляемый Subscription.

  • связь зависит от простой формы управления потоком (метод Subscription.request, для связывать обратное давление) которое может быть используется для предотвращения проблем управления ресурсами, которые могут возникнуть в системы на основе "push". Ля класс полезности SubmissionPublisher предоставляется которые разработчики могут использовать для создания пользовательских компонентов.

  • эти (очень малые) интерфейсы соответствуют интерфейсам, определенным с широким участием (от инициативы реактивных потоков) и поддержка взаимодействия в нескольких асинхронных системах, работающих на JVMs.

  • вложенность интерфейсов в классе является консервативная политика позволяет их использование в различных краткосрочных и долгосрочных возможностей. Там не планируется предоставлять сеть-или I/O-based java.util.concurrent компоненты для распределенных сообщений,но возможно, что будущий JDK релизы будут включать такие API в другие пакеты.

почему кто-то использует библиотеку потока Java 9 над гораздо более разнообразной библиотекой RxJava или вице наоборот?

глядя на более широкую перспективу, это полностью мнение, основанное на таких факторах, как тип приложения, которое разрабатывает клиент, и его использование фреймворка.