Promote reactive integrations to stable API

[qwwdfsad]

No description provided.

[dkhalanskyjb]

An overview of the current problems:

• Various incompatibilities with the Reactive Streams spec
  • publish { } permits emitting nullable values (fixed in Consistently handle exceptions in reactive streams #2646)
  • reactorPublish { } throws when given something other than CorePublisher (a problem that can't realistically arise currently) (fixed in Fixes for the Reactor integration #2622)
  • reactorPublish { } permits emitting nullable values (Reactor docs explicitly say that nulls are not supported) (fixed in Add the missing type boundaries to the reactive integrations #2630) Source-incompatible change that we won't make.
  • ReactiveSubscriber throws in onNext if the channel is full (though looks like this can only happen with misbehaving publishers)
• Doc improvements (fixed in Fixes for the reactive integrations #2617)
  • Some docs don't describe error handling sufficiently
  • Wrong references or lack of references
• Missing useful methods
  • Publisher<T>.awaitSingleOr* in the JDK9 Flow integration (9b210e4) we deprecate these methods instead
  • ObservableSource<T>.awaitSingleOr* in the Rx integration we deprecate these methods instead
  • await awaitSingleOrNull on Reactor's Mono (Add await() extension on Rector Mono type #1587, fixed in Deprecate awaitSingleOr*, specialize some await* functions for Mono and Maybe #2628)
  • Building a CoroutineContext element from Reactor's ContextView (Make ReactorContext accept ContextView #2575, fixed in Fixes for the Reactor integration #2622)
• Bugs
  • MaybeSource.collect hangs on success (fixed in Fixes for the reactive integrations #2617)
  • awaitSingleOrNull is broken (awaitSingleOrNull returns not nullable value #2591, fixed in Deprecate awaitSingleOr*, specialize some await* functions for Mono and Maybe #2628)
  • In publish, flux, rxFlowable, and rxObservable, isClosedForSend doesn't immediately start returning false after close
  • Sometimes various of our publishers call onComplete even before the end of the stream is reached if cancellation occurred (fixed in Consistently handle exceptions in reactive streams #2646)
  • trySend for publish { ... }, flux { ... }, rxFlowable { ... }, and rxObservable { ... } may sometimes throw (fixed in Consistently handle exceptions in reactive streams #2646)
  • mono ignores cancellations (mono { } with timeout never completes #2262, fixed in Complete mono { } on cancellation #2606)
  • publish, rxFlowable, and flux ignore cancellations (fixed in Consistently handle exceptions in reactive streams #2646)
  • mono doesn't have the <T: Any> boundary, which makes it look like it can emit null, when in reality, null is reserved to mean the lack of a value. (fixed in Add the missing type boundaries to the reactive integrations #2630) Source-incompatible change that we won't make.
  • rxMono doesn't have the <T: Any> boundary (fixed in Add the missing type boundaries to the reactive integrations #2630) Source-incompatible change that we won't make.
• Error handling issues
  • Handling fatal exceptions in RxJava (Inconsistent handling of undeliverable errors in RX builders #2173, fixed in Consistently handle exceptions in reactive streams #2646) The root cause for the problem is (3.x) LambdaSubscriber violates the Reactive Streams spec ReactiveX/RxJava#7217, with RxJava's position being that the users must make sure not to allow fatal exceptions to propagate to the Rx machinery.
  • We inconsistently handle errors thrown from the handlers (fixed in Consistently handle exceptions in reactive streams #2646)
    • In Rx, in handleUndeliverableException, if RxJavaPlugins.onError throws, the original exception is passed to handleCoroutineException. It seems that the only way RxJavaPlugins.onError could throw now is due to an IO error when printing the stack trace.
    • In Reactor's mono, if onError throws, the original exception is passed. It suffices to add a throwing function to the onOperatorError hook to make the error condition trigger.
    • In FlowSubscription and PublisherCoroutine, if the error handler itself throws, we rethrow the new error. Note: both of these could only happen due to a faulty Subscriber.
    • In REACTOR_HANDLER, if the error handler throws, the new error is rethrown, though there it could be unintentional and due to shadowing. Like in mono, this is easy to trigger.

Dispatching

• Suboptimal execution context guarantees (Thread switching and interoperability using rxSingle wrapper #2485): when subscribing to a publisher in an RxJava or Reactor chain, the chain itself may impose restrictions on where execution should happen (with observeOn() and such), but we ignore that and launch the coroutines in the default dispatcher. Maybe open an event loop on the provided threads instead?
• Using a CoroutineDispatcher as an RxJava Scheduler (Allow converting CoroutineDispatcher to RxJava scheduler #968, Way to use a CoroutineDispatcher as a RxJava Scheduler #548, with a PR in progress Add way to convert CoroutineDispatcher to Scheduler  #1923)

[qwwdfsad]

Fixed in 1.5.0, the rest is not the part of stabilization