RxJava 3 Support

[ZacSweers]

RxJava 3 is planned for later this year, but will use the same maven coordinates and package name. There is one significant change that affects AutoDispose: the as() operator has been folded back into to(), where the original to() overloads accepting Functions has been replaced with as()'s use of custom converter interfaces.

For Java consumers - this basically means no change is required from the AutoDispose side. Consumers would need to switch to to(), but all the static autoDisposable() APIs would work out of the box with that in RxJava 3. All we need to do is update docs for usage in both.

This does present an interesting problem for the kotlin extensions though, which all call through to .as() under the hood and would no longer function in RxJava 3.

My current thoughts right now are to try to avoid requiring a V2 for AutoDispose, and instead make RxJava 3 support somehow opt-in. An idea for this is to wrap support behind an abstraction in an rx3-only module compiled against rxjava 3. Then you can opt in the kotlin extensions to this via new AutoDispose plugin, and under the hood it would switch to use the rx3 support.

The rx3 support module would have something like this

// Ugly name but we can't mark this as internal since it's another module, but maybe we can make it harder to discover
fun <T> Observable<T>.rx3toInteropForAutoDispose(converter: ObservableConverter<T, ObservableSubscribeProxy<T>>): ObservableSubscribeProxy<T> = to(converter)

Then in the main kotlin extensions we'd do something like this

fun <T> Observable<T>.autoDisposable(scope: ScopeProvider): ObservableSubscribeProxy<T> {
  val converter = AutoDispose.autoDisposable<T>(scope)
  return if (AutoDisposePlugins.useRx3()) {
    rx3toInteropForAutoDispose(converter)
  } else {
    `as`(converter)
  }
}

We'd need to add some sort of proguard warning suppression for consumers not using rx3 to safely ignore it missing from the classpath

[ZacSweers]

Alternatively - maybe we can use -Xfriend-paths to allow making the interop function internal but still accessible from autodispose artifacts

[ZacSweers]

We'd also need to update static analysis tools to handle both. I think that could be easy if we basically just check the signature of to() first

[ZacSweers]

we could also make the autodispose plugin more functional in nature, so we can skip the if-check. Main issue is that the plugins are written in java but the interop function would be kotlin

[ZacSweers]

Another incompatibility: defer factories have now changed to use Supplier instead of Callable: https://github.com/ReactiveX/RxJava/blob/3.x/src/main/java/io/reactivex/Completable.java#L358

That throws another wrench in trying to support both

[ShaishavGandhi]

Seems like we're going to get a new package and groupId
ReactiveX/RxJava#6606 (comment)

[ZacSweers]

Better than before but still annoying for us as we'll need to release a new artifact pointing to that package as well. I wonder if there's a way we can support both in builds somehow

[ZacSweers]

After we release 1.4.0, we'll start 2.x snapshots pointing to rxjava 3