« Changelog History


Reactive Streams v1.0.4 Release Notes

Release Date: 2022-05-20 // almost 2 years ago

  • Announcement:

    ⚡️ We—the Reactive Streams community—are pleased to announce the immediate availability of Reactive Streams 1.0.4. This update to Reactive Streams brings the following improvements over 1.0.3.

    Highlights:

    • License
      • This project is now (re-)licensed under MIT No Attribution (SPDX: MIT-0)
    • Specification
    • Interfaces
      • No changes
    • Technology Compatibility Kit (TCK)
      • Improved verification of Subscriber rule §2.3
      • Improved JavaDoc
    • Examples
      • No changes
    • Artifacts
      • No changes

    Specification clarifications 1.0.4

    Subscriber Rule 7

    1.0.3: 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.

    1.0.4: 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 serial relation between each of the calls is established.

    Contributors


Previous changes from v1.0.3

  • Announcement:

    ⚡️ We—the Reactive Streams community—are pleased to announce the immediate availability of Reactive Streams 1.0.3. This update to Reactive Streams brings the following improvements over 1.0.2.

    Highlights:

    • Specification
    • Interfaces
      • No changes
    • Technology Compatibility Kit (TCK)
    • Examples
      • No changes
    • Artifacts
      • FlowAdapters artifact removed, FlowAdapters moved into the core jar (#424)

    Specification clarifications 1.0.3

    🔀 Glossary term "External synchronization" replaced by "Serial(ly)"

    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.

    Publisher Rule 3 (Rule and Intent clarified)

    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.

    Subscriber Rule 1 (Intent clarified)

    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.

    Subscriber Rule 5 (Intent clarified)

    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.

    Subscriber Rule 7 (Rule and Intent clarified)

    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.

    TCK alterations 1.0.3

    • PublisherVerification.optional_spec105_emptyStreamMustTerminateBySignallingOnComplete fails if the publisher completes synchronously (#422)
    • IdentityFlowProcessorVerification throws NPE when createFailedFlowPublisher returns null (#425)
    • required_spec208_mustBePreparedToReceiveOnNextSignalsAfterHavingCalledSubscriptionCancel does not wait for request before invoking onNext (#277)
    • ✅ Subscriber whitebox verification tests demand (#280)
    • 📚 Incomplete documentation on stochastic tests in TCK (#278)
    • 🐎 TCK performance (#446)
    • ⏱ TCK: Receptacle#expectError timeout approach (#451)

    Contributors