Decouple from ReactiveStreams interfaces

[NiteshKant]

Motivation

With the recent developments in JDK and the introduction of Flow, ReactiveStreams isn't a single standard API.
In the future we may see more adoption of Flow since it is part of the JDK.
In such situations extending from ReactiveStreams becomes a risk such that if everyone uses Flow, ServiceTalk may look like an outdated library.
We should provide our own contract and refer to ReactiveStreams in the documentation to make sure we convey that we are spec compliant.

Modification

• Introduced PublisherSource as a replacement for RS interfaces.
• Publisher in concurrent-api now implements PublisherSource instead of RS Publisher
• Renamed Single and Completable in concurrent module to SingleSource and CompletableSource to match PublisherSource.

Result

No direct dependency on ReactiveStreams.

[ddossot]

😅🚀

[jayv]

Overall makes sense, as discussed, some question around references and imports / line length issues.

[jayv]

Should we make reference to reference JDK Flow as well?

[NiteshKant]

JDK Flow is a replica of ReactiveStreams and does not do a good job in referencing to the specifications. I am not sure there is value in doing that now, we can update documentation later if required.

[jayv]

With the recent developments in JDK and the introduction of Flow, ReactiveStreams isn't a single standard API. [...]

...we start the PR with the above msg and then never mention Flow at all, strange.

JDK Flow is a replica of ReactiveStreams and does not do a good job in referencing to the specifications

1st paragraph of j.u.c.Flow API [1] links to the spec:

These interfaces correspond to the reactive-streams specification.

If we're assuming Flow will become a more predominant bridge interface, what is our strategy regarding implementing/converting the Flow.* types?
Do we expect the user to provide adapters or will we provide these once we also target JDK 11 ?

[1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/Flow.html

[NiteshKant]

we start the PR with the above msg and then never mention Flow at all, strange.

The motivation for this change is that there are more than one SPIs now in this space, hence the mention of Flow which is the second SPI after reactive streams.

me:

does not do a good job in referencing to the specifications.

@jayv

1st paragraph of j.u.c.Flow API [1] links to the spec:

Flow does not do a good job in referencing to the spec because it mentions the spec in the parent class(Flow) but does not get specified anywhere on the actual interfaces (Publisher, Subscriber, Subscription, Processor). To make the lack of reference to the spec more problematic, it defines some rules/behavior on the interfaces again w/o referring to the spec rules. Due to these reasons, I feel referring to Flow isn't really adding value here in our docs (if not making it ambiguous). We are basically following reactive streams for spec and TCK. Since, this is just documentation, we do not really have to be exhaustive in which contracts are similar to RS but just what we are following, which is reactive streams.

If we're assuming Flow will become a more predominant bridge interface,

We are not assuming Flow to be more predominant but we are not assuming the reverse too. This change is just acknolwedging the fact that there are more than one SPIs existing now hence making the choice to stick to one of them (API wise) is risky. Having our own contract for the sources and then providing adapters for all potential SPIs reduces that risk.

Do we expect the user to provide adapters or will we provide these once we also target JDK 11 ?

Reactive streams provide reactive streams to flow adapters today[1] which can be used by users but it would require two step adaptations (ST types -> RS types -> Flow). Once we require JDK 11, then we can provide direct adapters to Flow.

[1] https://github.com/reactive-streams/reactive-streams-jvm/blob/master/api/src/main/java9/org/reactivestreams/FlowAdapters.java

[NiteshKant]

@jayv I have scanned all files for > 120 and unnecessary qualifiers for package names.

[Scottmitch]

quick glance ... lgtm