Description
There is an ongoing effort to clarify the reasons behind the Reactive-Streams rules. In the hopes that the rules could be relaxed without too much compatibility problems, I brought up the case that we had to introduce the strict() operator to pass the TCK tests. The problematic rules are §1.3 and §3.9 that impose such requirements that add overhead to sequences.
This sparked a separate discussion about the it was a good idea RxJava 2 exposes itself with the Reactive-Streams interfaces instead of hiding it behind a converter / exposure layer which decoupling allows - in theory - violating the exact rules as long as such violations are not visible by the consumer.
I doubt I could convince the maintainers of the specification (other than @smaldini) it is worth taking the relaxations even at the expense of temporary incompatibility in case vendor's don't relax their particular implementations.
RxJava 2 works with or without the "Reactive-Streams compliant" badge yet as a "brand", it is still advisable to have that badge.
Suggested API changes
Ensuring conformance is a matter of applying the StrictSubscriber wrapper to the incoming Subscriber in Flowable.subscribe. Unfortunately, this slows down everything as there is only one way to consume a Flowable through subscribe(Subscriber) (the overloads all delegate to it).
To get the speed back, a new instance method would be introduced that all internal operators would use then on instead of subscribe. RxJava 1 has an extra entry point unsafeSubscribe to sidestep SafeSubscriber thus there is precedence for such alternate entry point.
The method could be called subscribe as well that takes a FlowableSubscriber extends Subscriber. FlowableSubscribers textual definition can then weaken rules §1.3 and §3.9 inherited. Existing operators would then implement FlowableSubscriber in place of Subscriber.
I think all of this would be binary compatible change since only Flowable would get an extra method.
Suggestions welcome.