Reactive Streams 1.0.0 – a new standard in reactive data processing
Reactive Streams 1.0.0 has reached its objective of defining a common standard for asynchronous streaming processes on the JVM, for flexible and reactive data processing.
Since February 2014, representatives from Typesafe, Red Hat, Netflix, Pivotal, Oracle, Twitter and spray.io have been collaborating in various work groups to define a standard for asynchronous data streaming on the JVM. Not an easy task, considering what it was that Reactive Streams was aiming for: to “provide a standard for asynchronous stream processing with non-blocking back pressure.”
“[A]fter countless hours of prototyping, discussions, debate, evaluations, programming, testing, specifying requirements, documenting, and refining—we are confident that we have found the essential solution to the problem that we set out to solve.”
Over on Hacker News, the response to news of Reactive Streams arriving on the JVM has been largely positive, although some users are confused by the term ‘back pressure’. So-called ‘back pressure‘ allows a stream receiver to inform the source via a return channel whether or not it can accommodate more data – David Gross provides a nice introduction on GitHub.
Reactive Streams on the JVM
Following a number of recent improvements, such as the implementation of Akka streams, the final version of Reactive Streams 1.0.0 has now been made available. Alongside Akka streams, other technologies like MongoDB, Ratpack, Reactor, RxJava and Vert.x 3.0 have also been implemented. A link list of implementations and the relevant documentation can be found on the project page, while the JVM specification source code can been seen here on GitHub, along with plenty more details about the release.
In this latest development, the Reactive Stream Interest Group continues to adhere to the parameters of reactive software development, which were laid out in the Reactive Manifesto. In the recently re-edited manifesto, four requirements for reactive software systems are outlined: responsiveness, resilience, elasticity and being message-driven. The interest group hopes to be represented in future JDK specifications with a standard that follows these principles on asynchronous data processing.