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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

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

• Интерфейсы, поддерживающие Reactive Streams publish-subscribe framework, вложенный в новый класс Flow.

• Publisher производить элементы потребляемый одним или несколькими Subscriber s, каждый из которых управляется Subscription.

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

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

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

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

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