- Walls, Craig (October 2019). Spring in Action (Fifth ed.). Manning. p. 520. ISBN 9781617294945.
This article incorporates text from www.reactive-streams , which is released under a CC0 1.0 Universal (CC0 1.0) Public Domain Dedication..org
| Initial release | 15 May 2015 |
|---|---|
| Stable release | 1.0.3
/ 23 August 2019 |
| Repository | github |
| Written in | Java (Scala, Groovy, Kotlin), .NET |
| Website | reactive-streams |
Reactive Streams is an initiative to provide a standard for asynchronous stream processing with non-blocking back pressure.[1][2]
Reactive Streams started as an initiative in late 2013 between engineers at Netflix, Pivotal and Lightbend. Some of the earliest discussions began in 2013 between the Play and Akka teams at Lightbend.[3][4] Lightbend is one of the main contributors of Reactive Streams.[5] Other contributors include Red Hat, Oracle, Twitter and spray.io.[6]
The main goal of Reactive Streams is to govern the exchange of stream data across an asynchronous boundary – like passing elements on to another thread or thread-pool – while ensuring that the receiving side is not forced to buffer arbitrary amounts of data. In other words, back pressure is an integral part of this model in order to allow the queues which mediate between threads to be bounded.
The intention of the specification is to allow the creation of many conforming implementations, which by virtue of abiding by the rules will be able to interoperate smoothly, preserving the mentioned benefits and characteristics across the whole processing graph of a stream application. A freely-available Technology Compatibility Kit[7] was developed alongside the specification that allows implementors of the specification to verify if they covered all rules and requirements, including checks for potential race conditions.
The scope of Reactive Streams is a minimal set of interfaces, methods and protocols that describe the necessary operations and entities to achieve the asynchronous streams of data with non-blocking back pressure.[2] End-user DSLs or protocol binding APIs have purposefully been left out of the scope to encourage and enable different implementations that potentially use different programming languages to stay as true as possible to the idioms of their platform.
The specification developed with the intent of future inclusion in the official Java standard library, if proven successful and adopted by enough libraries and vendors.
Reactive Streams were proposed to become part of Java 9 by Doug Lea, leader of JSR 166[8] as a new Flow class[9] that would include the interfaces currently provided by Reactive Streams.[5][10] After a successful 1.0 release of Reactive Streams and growing adoption, the proposal was accepted and Reactive Streams was included in JDK9 via the JEP-266.[10]
On April 30, 2015 version 1.0.0 of Reactive Streams for the JVM was released,[5][6][11] including Java API,[12] a textual specification,[13] a TCK and implementation examples. It comes with a multitude of compliant implementations verified by the TCK for 1.0.0, listed in alphabetical order:[11]
Other implementations include Cassandra,[23] Elasticsearch,[24] Apache Kafka,[25] Parallel Universe Quasar,[26] Play Framework,[27] Armeria.[28]
Spring 5 is announced to be built upon Reactive Streams compatible Reactor Core.[29]
Amazon announced that its Amazon Web Services SDK would support Reactive Streams to provide streaming capabilities in its client libraries in version 2.0.[30]
Reactive Streams 1.0.1 is released on August 9, 2017, including various improvements in specification preciseness, TCK improvements and other clarifications. The specification as well as interfaces remained fully backwards compatible with the 1.0.0 version, however aimed to streamline the adoption for future implementors as well as align with some additional requirements set by the OpenJDK.[31]