Skip to content

Commit ec44e03

Browse files
viktorklangviktorklang
committed
Version 1.0.1
1 parent c48b6b7 commit ec44e03

File tree

4 files changed

+175
-10
lines changed

4 files changed

+175
-10
lines changed

‎README.md

+6-6
Original file line numberDiff line numberDiff line change
@@ -8,12 +8,12 @@ The latest release is available on Maven Central as
88
<dependency>
99
<groupId>org.reactivestreams</groupId>
1010
<artifactId>reactive-streams</artifactId>
11-
<version>1.0.0</version>
11+
<version>1.0.1-RC1</version>
1212
</dependency>
1313
<dependency>
1414
<groupId>org.reactivestreams</groupId>
1515
<artifactId>reactive-streams-tck</artifactId>
16-
<version>1.0.0</version>
16+
<version>1.0.1-RC1</version>
1717
<scope>test</scope>
1818
</dependency>
1919
```
@@ -83,7 +83,7 @@ followed by a possibly unbounded number of `onNext` signals (as requested by `Su
8383

8484
### SPECIFICATION
8585

86-
#### 1. Publisher ([Code](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/api/src/main/java/org/reactivestreams/Publisher.java))
86+
#### 1. Publisher ([Code](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.1-RC1/api/src/main/java/org/reactivestreams/Publisher.java))
8787

8888
```java
8989
public interface Publisher<T> {
@@ -116,7 +116,7 @@ public interface Publisher<T> {
116116
| <a name="1.11">11</a> | A `Publisher` MAY support multiple `Subscriber`s and decides whether each `Subscription` is unicast or multicast. |
117117
| [:bulb:](#1.11 "1.11 explained") | *The intent of this rule is to give Publisher implementations the flexibility to decide how many, if any, Subscribers they will support, and how elements are going to be distributed.* |
118118

119-
#### 2. Subscriber ([Code](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/api/src/main/java/org/reactivestreams/Subscriber.java))
119+
#### 2. Subscriber ([Code](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.1-RC1/api/src/main/java/org/reactivestreams/Subscriber.java))
120120

121121
```java
122122
public interface Subscriber<T> {
@@ -156,7 +156,7 @@ public interface Subscriber<T> {
156156
| <a name="2.13">13</a> | Calling `onSubscribe`, `onNext`, `onError` or `onComplete` MUST [return normally](#term_return_normally) except when any provided parameter is `null` in which case it MUST throw a `java.lang.NullPointerException` to the caller, for all other situations the only legal way for a `Subscriber` to signal failure is by cancelling its `Subscription`. In the case that this rule is violated, any associated `Subscription` to the `Subscriber` MUST be considered as cancelled, and the caller MUST raise this error condition in a fashion that is adequate for the runtime environment. |
157157
| [:bulb:](#2.13 "2.13 explained") | *The intent of this rule is to establish the semantics for the methods of Subscriber and what the Publisher is allowed to do in which case this rule is violated. «Raise this error condition in a fashion that is adequate for the runtime environment» could mean logging the error—or otherwise make someone or something aware of the situation—as the error cannot be signalled to the faulty Subscriber.* |
158158

159-
#### 3. Subscription ([Code](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/api/src/main/java/org/reactivestreams/Subscription.java))
159+
#### 3. Subscription ([Code](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.1-RC1/api/src/main/java/org/reactivestreams/Subscription.java))
160160

161161
```java
162162
public interface Subscription {
@@ -204,7 +204,7 @@ public interface Subscription {
204204

205205
A `Subscription` is shared by exactly one `Publisher` and one `Subscriber` for the purpose of mediating the data exchange between this pair. This is the reason why the `subscribe()` method does not return the created `Subscription`, but instead returns `void`; the `Subscription` is only passed to the `Subscriber` via the `onSubscribe` callback.
206206

207-
#### 4.Processor ([Code](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/api/src/main/java/org/reactivestreams/Processor.java))
207+
#### 4.Processor ([Code](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.1-RC1/api/src/main/java/org/reactivestreams/Processor.java))
208208

209209
```java
210210
public interface Processor<T, R> extends Subscriber<T>, Publisher<R> {

‎RELEASE-NOTES.md

+166-1
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,168 @@
11
# Release notes for Reactive Streams
22

3-
Changes will be listed below after version 1.0.0 is released.
3+
---
4+
5+
# Version 1.0.1-RC1 released on 2017-06-29
6+
7+
## Announcement:
8+
9+
After more than two years since 1.0.0, we are proud to announce the immediate availability of `Reactive Streams version 1.0.1-RC1`.
10+
11+
Since 1.0.0 was released `Reactive Streams` has managed to achieve most, if not all, it set out to achieve. There are now numerous implementations, and it is scheduled to be included in [JDK9](http://download.java.net/java/jdk9/docs/api/java/util/concurrent/Flow.html).
12+
13+
Also, most importantly, there are no semantical incompatibilities included in this release.
14+
15+
When JDK9 ships, `Reactive Streams` will publish a compatibility/conversion library to seamlessly convert between the `java.util.concurrent.Flow` and the `org.reactivestreams` namespaces.
16+
17+
## Highlights:
18+
19+
- Specification
20+
+ A new [Glossary](https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.1-RC1/README.md#glossary) section
21+
+ Description of the intent behind every single rule
22+
+ No breaking semantical changes
23+
+ Multiple rule [clarifications](#specification-clarifications)
24+
- Interfaces
25+
+ No changes
26+
+ Improved JavaDoc
27+
- Technology Compatibility Kit (TCK)
28+
+ Improved coverage
29+
+ Improved JavaDoc
30+
+ Multiple test [alterations](#tck-alterations)
31+
32+
## Specification clarifications
33+
34+
## Publisher Rule 1
35+
36+
**1.0.0:** The total number of onNext signals sent by a Publisher to a Subscriber MUST be less than or equal to the total number of elements requested by that Subscriber´s Subscription at all times.
37+
38+
**1.0.1:** The total number of onNext´s signalled by a Publisher to a Subscriber MUST be less than or equal to the total number of elements requested by that Subscriber´s Subscription at all times.
39+
40+
**Comment: Minor spelling update.**
41+
42+
## Publisher Rule 2
43+
44+
**1.0.0:** A Publisher MAY signal less onNext than requested and terminate the Subscription by calling onComplete or onError.
45+
46+
**1.0.1:** A Publisher MAY signal fewer onNext than requested and terminate the Subscription by calling onComplete or onError.
47+
48+
**Comment: Minor spelling update.**
49+
50+
## Publisher Rule 3
51+
52+
**1.0.0:** onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled sequentially (no concurrent notifications).
53+
54+
**1.0.1:** 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.
55+
56+
**Comment: Reworded the part about sequential signal and its implications, for clarity.**
57+
58+
## Subscriber Rule 6
59+
60+
**1.0.0:** A Subscriber MUST call Subscription.cancel() if it is no longer valid to the Publisher without the Publisher having signaled onError or onComplete.
61+
62+
**1.0.1:** A Subscriber MUST call Subscription.cancel() if the Subscription is no longer needed.
63+
64+
**Comment: Rule could be reworded since it now has an intent section describing desired effect.**
65+
66+
## Subscriber Rule 11
67+
68+
**1.0.0:** A Subscriber MUST make sure that all calls on its onXXX methods happen-before [1] the processing of the respective signals. I.e. the Subscriber must take care of properly publishing the signal to its processing logic.
69+
70+
**1.0.1:** A Subscriber MUST make sure that all calls on its signal methods happen-before the processing of the respective signals. I.e. the Subscriber must take care of properly publishing the signal to its processing logic.
71+
72+
**Comment: Rule slightly reworded to use the glossary for `signal` instead of the more *ad-hoc* name "onXXX methods". Footnote was reworked into the Intent-section of the rule.**
73+
74+
## Subscription Rule 1
75+
76+
**1.0.0:** Subscription.request and Subscription.cancel MUST only be called inside of its Subscriber context. A Subscription represents the unique relationship between a Subscriber and a Publisher [see 2.12].
77+
78+
**1.0.1:** Subscription.request and Subscription.cancel MUST only be called inside of its Subscriber context.
79+
80+
**Comment: Second part of rule moved into the Intent-section of the rule.**
81+
82+
## Subscription Rule 3
83+
84+
**1.0.0:** Subscription.request MUST place an upper bound on possible synchronous recursion between Publisher and Subscriber[1].
85+
86+
**1.0.1:** Subscription.request MUST place an upper bound on possible synchronous recursion between Publisher and Subscriber.
87+
88+
**Comment: Footnote reworked into the Intent-section of the rule.**
89+
90+
## Subscription Rule 4
91+
92+
**1.0.0:** Subscription.request SHOULD respect the responsivity of its caller by returning in a timely manner[2].
93+
94+
**1.0.1:** Subscription.request SHOULD respect the responsivity of its caller by returning in a timely manner.
95+
96+
**Comment: Footnote reworked into the Intent-section of the rule.**
97+
98+
## Subscription Rule 5
99+
100+
**1.0.0:** Subscription.cancel MUST respect the responsivity of its caller by returning in a timely manner[2], MUST be idempotent and MUST be thread-safe.
101+
102+
**1.0.1:** Subscription.cancel MUST respect the responsivity of its caller by returning in a timely manner, MUST be idempotent and MUST be thread-safe.
103+
104+
**Comment: Footnote reworked into the Intent-section of the rule.**
105+
106+
## Subscription Rule 13
107+
108+
**1.0.0:** While the Subscription is not cancelled, Subscription.cancel() MUST request the Publisher to eventually drop any references to the corresponding subscriber. Re-subscribing with the same Subscriber object is discouraged [see 2.12], but this specification does not mandate that it is disallowed since that would mean having to store previously cancelled subscriptions indefinitely.
109+
110+
**1.0.1:** While the Subscription is not cancelled, Subscription.cancel() MUST request the Publisher to eventually drop any references to the corresponding subscriber.
111+
112+
**Comment: Second part of rule reworked into the Intent-section of the rule.**
113+
114+
## Subscription Rule 15
115+
116+
**1.0.0:** Calling Subscription.cancel MUST return normally. The only legal way to signal failure to a Subscriber is via the onError method.
117+
118+
**1.0.1:** Calling Subscription.cancel MUST return normally.
119+
120+
**Comment: Replaced second part of rule with a definition for `return normally` in the glossary.**
121+
122+
## Subscription Rule 16
123+
124+
**1.0.0:** Calling Subscription.request MUST return normally. The only legal way to signal failure to a Subscriber is via the onError method.
125+
126+
**1.0.1:** Calling Subscription.request MUST return normally.
127+
128+
**Comment: Replaced second part of rule with a definition for `return normally` in the glossary.**
129+
130+
## Subscription Rule 17
131+
132+
**1.0.0:** A Subscription MUST support an unbounded number of calls to request and MUST support a demand (sum requested - sum delivered) up to 2^63-1 (java.lang.Long.MAX_VALUE). A demand equal or greater than 2^63-1 (java.lang.Long.MAX_VALUE) MAY be considered by the Publisher as “effectively unbounded”[3].
133+
134+
**1.0.1:** A Subscription MUST support an unbounded number of calls to request and MUST support a demand up to 2^63-1 (java.lang.Long.MAX_VALUE). A demand equal or greater than 2^63-1 (java.lang.Long.MAX_VALUE) MAY be considered by the Publisher as “effectively unbounded”.
135+
136+
**Comment: Rule simplified by defining `demand` in the glossary, and footnote was reworked into the Intent-section of the rule.**
137+
138+
---
139+
140+
## TCK alterations
141+
142+
- Fixed potential resource leaks in partially consuming Publisher tests ([#375](https://github.com/reactive-streams/reactive-streams-jvm/issues/375))
143+
- Fixed potential resource leaks in partially emitting Subscriber tests ([#372](https://github.com/reactive-streams/reactive-streams-jvm/issues/372), [#373](https://github.com/reactive-streams/reactive-streams-jvm/issues/373))
144+
- Renamed `untested_spec305_cancelMustNotSynchronouslyPerformHeavyCompuatation` to `untested_spec305_cancelMustNotSynchronouslyPerformHeavyComputation` ([#306](https://github.com/reactive-streams/reactive-streams-jvm/issues/306))
145+
- Allow configuring separate timeout for "no events during N time", allowing for more aggressive timeouts in the rest of the test suite if required ([#314](https://github.com/reactive-streams/reactive-streams-jvm/issues/314))
146+
- New test verifying Rule 2.10, in which subscriber must be prepared to receive onError signal without having signaled request before ([#374](https://github.com/reactive-streams/reactive-streams-jvm/issues/374))
147+
---
148+
149+
## Contributors
150+
+ Roland Kuhn [(@rkuhn)](https://github.com/rkuhn)
151+
+ Ben Christensen [(@benjchristensen)](https://github.com/benjchristensen)
152+
+ Viktor Klang [(@viktorklang)](https://github.com/viktorklang)
153+
+ Stephane Maldini [(@smaldini)](https://github.com/smaldini)
154+
+ Stanislav Savulchik [(@savulchik)](https://github.com/savulchik)
155+
+ Konrad Malawski [(@ktoso)](https://github.com/ktoso)
156+
+ Slim Ouertani [(@ouertani)](https://github.com/ouertani)
157+
+ Martynas Mickevičius [(@2m)](https://github.com/2m)
158+
+ Luke Daley [(@ldaley)](https://github.com/ldaley)
159+
+ Colin Godsey [(@colinrgodsey)](https://github.com/colinrgodsey)
160+
+ David Moten [(@davidmoten)](https://github.com/davidmoten)
161+
+ (new) Brian Topping [(@briantopping)](https://github.com/briantopping)
162+
+ (new) Rossen Stoyanchev [(@rstoyanchev)](https://github.com/rstoyanchev)
163+
+ (new) Björn Hamels [(@BjornHamels)](https://github.com/BjornHamels)
164+
+ (new) Jake Wharton [(@JakeWharton)](https://github.com/JakeWharton)
165+
+ (new) Anthony Vanelverdinghe[(@anthonyvdotbe)](https://github.com/anthonyvdotbe)
166+
+ (new) Kazuhiro Sera [(@seratch)](https://github.com/seratch)
167+
+ (new) Dávid Karnok [(@akarnokd)](https://github.com/akarnokd)
168+
+ (new) Evgeniy Getman [(@egetman)](https://github.com/egetman)

‎build.gradle

+2-2
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,7 @@ subprojects {
33
apply plugin: "osgi"
44

55
group = "org.reactivestreams"
6-
version = "1.0.0"
6+
version = "1.0.1-RC1"
77

88
sourceCompatibility = 1.6
99
targetCompatibility = 1.6
@@ -42,7 +42,7 @@ subprojects {
4242
instructionReplace "Bundle-Vendor", "Reactive Streams SIG"
4343
instructionReplace "Bundle-Description", "Reactive Streams API"
4444
instructionReplace "Bundle-DocURL", "http://reactive-streams.org"
45-
instructionReplace "Bundle-Version", "1.0.0"
45+
instructionReplace "Bundle-Version", "1.0.1-RC1"
4646
}
4747
}
4848

‎tck/README.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ The TCK is provided as binary artifact on [Maven Central](http://search.maven.or
2727
<dependency>
2828
<groupId>org.reactivestreams</groupId>
2929
<artifactId>reactive-streams-tck</artifactId>
30-
<version>1.0.0</version>
30+
<version>1.0.1-RC1</version>
3131
<scope>test</scope>
3232
</dependency>
3333
```

0 commit comments

Comments
 (0)