Различие между RxJava API и потоком Java 9 API

Question 1

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

В Java 9 у нас есть Поток API, который напоминает Текучий API RxJava, но с Java 9 имеет намного более простой набор классов и интерфейсов.

Java 9

Имеет a Flow.Publisher, Flow.Subscriber, Flow.Processor, Flow.Subscription, и SubmissionPublisher, и это об этом.

RxJava

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

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

Question 2

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

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

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

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

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

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

До того времени, существует опытная библиотека, названная Reactive4JavaFlow, который действительно реализует Поток API и предлагает стилю ReactiveX богатый быстрый API по ней.

, Почему кто-то пользовался бы библиотекой Java 9 Flow по намного более разнообразной библиотеке RxJava или наоборот?

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

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

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

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

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

Question 3

Question 4

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

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

В то же время разработчики JDK поняли, что реактивный материал является большим и стоит включая в Java. Поскольку это обычно в мире Java, фактический стандарт становится де-юре. Remeber В спящем режиме и JPA, Время Joda и Дата/Время API Java 8? Таким образом, то, что сделал JDK develpers, извлекает очень базовые из реактивных API, наиболее базовой детали, и делает его стандартом. Именно так j.u.c.Flow родился.

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

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

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

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

Question 5

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

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

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

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

Question 6

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

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

Интерфейсы, поддерживающие , Реактивные Потоки публикуют - подписывают платформу , вложенный в новом классе Поток .
Publisher с производят объекты, использованные одним или несколькими Subscriber с, каждый управляемый Subscription.
Коммуникация полагается на простую форму управления потоком (метод Subscription.request, для передачи противодавления), который может использоваться для предотвращения проблем управления ресурсами, которые могут иначе произойти в основанных на "нажатии" системах. Служебный класс SubmissionPublisher - то, при условии, что разработчики могут использовать для создания пользовательских компонентов.
Эти (очень маленькие) интерфейсы соответствуют определенным с широким участием (от Реактивной Потоковой инициативы) и поддерживают совместимость через многие асинхронные системы, работающие на JVMs.
Вложение интерфейсы в классе консервативная политика, позволяющая их использование через различные краткосрочные и долгосрочные возможности . Нет никаких планов обеспечить сеть - или I/O-based java.util.concurrent компоненты для распределенного обмена сообщениями, , но возможно, что будущие выпуски JDK будут включать такие API в другие пакеты .

_{, Почему кто-то пользовался бы библиотекой Java 9 Flow по намного более разнообразной библиотеке RxJava или наоборот?}

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

akarnokd · Accepted Answer · 31 October 2019 в 14:06

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

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

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

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

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

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

До того времени, существует опытная библиотека, названная Reactive4JavaFlow, который действительно реализует Поток API и предлагает стилю ReactiveX богатый быстрый API по ней.

, Почему кто-то пользовался бы библиотекой Java 9 Flow по намного более разнообразной библиотеке RxJava или наоборот?

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

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

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

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

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

madhead · Answer 2 · 31 October 2019 в 14:06

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

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

В то же время разработчики JDK поняли, что реактивный материал является большим и стоит включая в Java. Поскольку это обычно в мире Java, фактический стандарт становится де-юре. Remeber В спящем режиме и JPA, Время Joda и Дата/Время API Java 8? Таким образом, то, что сделал JDK develpers, извлекает очень базовые из реактивных API, наиболее базовой детали, и делает его стандартом. Именно так j.u.c.Flow родился.

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

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

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

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

Piotr Wilkin · Answer 3 · 31 October 2019 в 14:06

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

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

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

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

Naman · Answer 4 · 31 October 2019 в 14:06

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

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

Интерфейсы, поддерживающие , Реактивные Потоки публикуют - подписывают платформу , вложенный в новом классе Поток .
Publisher с производят объекты, использованные одним или несколькими Subscriber с, каждый управляемый Subscription.
Коммуникация полагается на простую форму управления потоком (метод Subscription.request, для передачи противодавления), который может использоваться для предотвращения проблем управления ресурсами, которые могут иначе произойти в основанных на "нажатии" системах. Служебный класс SubmissionPublisher - то, при условии, что разработчики могут использовать для создания пользовательских компонентов.
Эти (очень маленькие) интерфейсы соответствуют определенным с широким участием (от Реактивной Потоковой инициативы) и поддерживают совместимость через многие асинхронные системы, работающие на JVMs.
Вложение интерфейсы в классе консервативная политика, позволяющая их использование через различные краткосрочные и долгосрочные возможности . Нет никаких планов обеспечить сеть - или I/O-based java.util.concurrent компоненты для распределенного обмена сообщениями, , но возможно, что будущие выпуски JDK будут включать такие API в другие пакеты .

_{, Почему кто-то пользовался бы библиотекой Java 9 Flow по намного более разнообразной библиотеке RxJava или наоборот?}

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

Различие между RxJava API и потоком Java 9 API

4 ответа

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

Другие вопросы по тегам:

Похожие вопросы: