We—the Reactive Streams Special Interest Group—are happy to announce the immediate availability of Reactive Streams version 1.0.3.
When we released 1.0.2, we shipped a compatibility/conversion library to seamlessly convert between the java.util.concurrent.Flow and the org.reactivestreams namespaces—in 1.0.3 these adapters are instead included in the main 1.0.3 jar.
In 1.0.3 we have improved the TCK, clarified different aspects of the specification, and proved that the Reactive Streams specification is robust and is successfully used by many various implementations.
As usual, 1.0.3 is binary, and semantically, compatible with the previous 1.0.x releases of Reactive Streams.
The artifacts, documentation and specifications are released under Creative Commons Zero into the Public Domain.
org.reactivestreams:reactive-streams:1.0.3org.reactivestreams:reactive-streams-tck:1.0.3org.reactivestreams:reactive-streams-tck-flow:1.0.3org.reactivestreams:reactive-streams-examples:1.0.3We’d like to thank everyone involved, all contributors and everyone who has given feedback during the development of this project.
1.0.2: Access coordination for thread safety purposes implemented outside of the constructs defined in this specification, using techniques such as, but not limited to, atomics, monitors, or locks.
1.0.3 In the context of a Signal, non-overlapping. In the context of the JVM, calls to methods on an object are serial if and only if there is a happens-before relationship between those calls (implying also that the calls do not overlap). When the calls are performed asynchronously, coordination to establish the happens-before relationship is to be implemented using techniques such as, but not limited to, atomics, monitors, or locks.
1.0.2: onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled in a thread-safe manner—and if performed by multiple threads—use external synchronization.
The intent of this rule is to make it clear that external synchronization must be employed if the Publisher intends to send signals from multiple/different threads.
1.0.3: onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled serially.
The intent of this rule is to permit the signalling of signals (including from multiple threads) if and only if a happens-before relation between each of the signals is established.
1.0.2: A Subscriber MUST signal demand via Subscription.request(long n) to receive onNext signals.
The intent of this rule is to establish that it is the responsibility of the Subscriber to signal when, and how many, elements it is able and willing to receive.
1.0.3: A Subscriber MUST signal demand via Subscription.request(long n) to receive onNext signals.
The intent of this rule is to establish that it is the responsibility of the Subscriber to decide when and how many elements it is able and willing to receive. To avoid signal reordering caused by reentrant Subscription methods, it is strongly RECOMMENDED for synchronous Subscriber implementations to invoke Subscription methods at the very end of any signal processing. It is RECOMMENDED that Subscribers request the upper limit of what they are able to process, as requesting only one element at a time results in an inherently inefficient “stop-and-wait” protocol.
1.0.2: A Subscriber MUST call Subscription.cancel() on the given Subscription after an onSubscribe signal if it already has an active Subscription
The intent of this rule is to prevent that two, or more, separate Publishers from thinking that they can interact with the same Subscriber. Enforcing this rule means that resource leaks are prevented since extra Subscriptions will be cancelled.
1.0.3: A Subscriber MUST call Subscription.cancel() on the given Subscription after an onSubscribe signal if it already has an active Subscription
The intent of this rule is to prevent that two, or more, separate Publishers from trying to interact with the same Subscriber. Enforcing this rule means that resource leaks are prevented since extra Subscriptions will be cancelled. Failure to conform to this rule may lead to violations of Publisher rule 1, amongst others. Such violations can lead to hard-to-diagnose bugs.
1.0.2: A Subscriber MUST ensure that all calls on its Subscription take place from the same thread or provide for respective external synchronization.
The intent of this rule is to establish that external synchronization must be added if a Subscriber will be using a Subscription concurrently by two or more threads.
1.0.3: A Subscriber MUST ensure that all calls on its Subscription’s request and cancel methods are performed serially.
The intent of this rule is to permit the calling of the request and cancel methods (including from multiple threads) if and only if a happens-before relation between each of the calls is established.
PublisherVerification.optional_spec105_emptyStreamMustTerminateBySignallingOnComplete fails if the publisher completes synchronously (#422)createFailedFlowPublisher returns null (#425)required_spec208_mustBePreparedToReceiveOnNextSignalsAfterHavingCalledSubscriptionCancel does not wait for request before invoking onNext (#277)Warm regards, the Reactive Streams Special Interest Group