3.x: Breaking API changes

This issue collects the API changes proposed for 3.x: unused operators and overloads, mistakes in signatures, etc.

• Remove: Flowable.subscribe(/* 4 args */) with Consumer<? super Subscription> -> #6517
• Remove: Observable.subscribe(/* 4 args */) with Consumer<? super Disposable> -> #6517
• Change: Completable.blockingGet() signature -> #6517
• Change: Maybe.defaultIfEmpty to return Single. -> #6517
• Change: X.to() to use dedicated non-generic functional type which then can be implemented by a single class for multiple base types. (#5654) -> #6514
• Remove: BehaviorSubject.getValues() -> #6516
• Remove: BehaviorProcessor.getValues() -> #6516
• Change: Single.toCompletable to Single.ignoreElement to be consistent with the other types. -> #6517
• Remove: AsyncSubject.getValues() -> #6516
• Remove: AsyncProcessor.getValues() -> #6516

[JakeWharton]

Libraries don’t need to match the releases of RxJava and there’s no reason to do this because of binary compatibility and dependency resolvers. If anything, libraries should be doing the opposite and expressing the minimum version they work with to not force behavior changes on their consumers unless desired.

To answer your specific questions…

How many libraries are using the operators in this list?

It’s impossible to know, of course, but it’s guaranteed to be more than zero.

Why are they using blockingGet in non-test code, for example?

This is a weird example considering it’s the least-used and least-useful of the bunch. So while it might be zero, the others are non-zero.

Do you replace a dependent libraries without recompiling/retesting the host library/application?

Of course. Transitive dependency resolution guarantees this to happen with libraries. It’s why we have jars and why Java does linking at runtime instead of statically at compile-time.

I’m almost certain RxAndroid, RxRelay, RxBinding, RxSharedPreferences either won’t have to change or would need a simple recompile if the Rx functional interfaces get widened to throws Throwable.

While this represents a popular set of libraries for Android, in the scope of the RxJava ecosystem it’s tiny. And this specific change is only source-incompatible, not binary-incompatible, so it’s not as worrying as the API changes.

There won’t be any architectural change with 3.x, create and X.subscribeActual will remain the same, as will fromCallable and the Scheduler/Worker API. JDK support will also remain 6.

This only reaffirms my belief that there’s no need for a version 3 right now. A useful RxJava 3 to me should be built against j.u.c.Flow and architected in a way to take advantage of Project Loom when it arrives.

Do you think 3rd party library authors are willing to support 2 versions, one for 2.x and one for 3.x, at the same time for an overlapping duration? What if the signature changes do not affect them at all?

Some did this for 1.x and 2.x, yes. But the interop library actually means you’re not even required to do it. The consumer of libraries could upgrade piecemeal by slowing moving the interop barrier across their application until the need for it was removed.

Why do you think I have the time or will to support two versions, again?

I don’t even want an RxJava 3 so I’m not asking you to. But beyond that, there’s plenty of people around this project that can and will help.

Later on in the post your plan outlines that you’re already going to support both though so based on that you seem to think you have the time.

Why would I have to spend time answering SO questions/issue questions about why Schedulers.io() no longer compiles because the OP forgot to change the import to like io.reactivex.rxjava3?

Are these going to number greater or less than the NoSuchMethodError posts? And the answer easier or harder to explain? But, again, there’s a whole community that can help do this and it’s the point of StackOverflow’s whole system.

RxJava’s API has to improve

Sure, but it needs some carrot balanced with the stick.

Right now the value proposition of 3.x is practically non-existent for consumers. We get a few warts fixed, sure, but at a cost that disproportional to the benefit.

as the minor inconveniences turn into major ones over time.

On a long enough timeline they might, but are these really at that point? None of the proposed changes unlock some fundamental potential that’s missing.

Also I’m pretty positive about the ecosystem’s flexibility; they will move forward as well, sooner or later.

I am too. Except actions like this will actually force a subset to alternate solutions which aren’t hostile to their builds which is unfortunate. Or they’ll simply stay on 2.x.

we release under the new package structure -> almost no libraries for months.

Does this matter? It doesn’t affect this library. At least in this case when consumers want to upgrade they can do so incrementally without a flag day where everything needs to change at once.

I want to see a 3.x that moves the goal posts for what a reactive library can be and makes Reactor look obsolete. Not something that fixes a few dings in the paint of its bumper.

[eygraber]

As an Android developer, I’d be fine with sticking on RxJava2 until there was an actual need for a major version bump. And neither I, nor anyone I know have abandoned RxJava for coroutines when the use case calls for it, which is often. Some of us are quite bought-in to rx.

I really wouldn’t mind seeing RxJava (or a reactive implementation) built on coroutines but that’s more for ease of implementing operators (which isn’t so bad with Kotlin because of extensions). I guess it would just be cool.