3.x: Single or split library.

RxJava 2 is quite a beast with several foundational types (Flowable, ParallelFlowable, Observable, Single, Maybe, Completable) with extensive API surfaces and considerable jar file size.

Arguments for splitting:

• Less conceptional weight due to the backpressure/no-backpressure difference between them.
• Flow-supporting parts, such as Disposable, Scheduler, SimpleQueue and other support can be factored out.
• Smaller download size.

Arguments against:

• RxJava 2 ProGuards quite well
• The need to introduce 4 artifacts: common, flowable, observable, interop. The interop is required as the flowable and observable can no longer reference each other.
• Should they share the same version or have independent versions?

[artem-zinnatullin]

I vote for not splitting for now.

Potential issues of splitting:

• Users will sometimes pull different component versions into single project and have complicated compatibility issues (because of transitive deps for instance) and we’ll see issues here and questions on StackOverflow about that. It happens with Kotlin (different reflection-lib revision is particularly hard to figure out), it happens with Android support library (there is even a Lint rule that checks that now) & other projects, and it’s painful
• It will make interop between rx types painful for Java users, they’ll have to use static methods. It’s RxJava, we have to think about Java users
• It raises a valid question of splitting observable into observable, single, maybe, completable, but interop for Java will be even more painful then
• If observable artifact will be much more popular than flowable, then it will potentially make RxJava more independent from Reactive Streams Spec (as 1.x was) which can lead to feature requests and internal changes that’ll be even less compatible with the spec and make maintenance harder
• “Less conceptional weight” will most likely become “More conceptional weight”, because user will have to figure out which part of RxJava to use, how to interop and so on. People already misuse RxAndroid/RxKotlin/etc, split inside RxJava itself will make it even worse

[akarnokd]

I decided the library won’t be split in 3.x due to an excessive amount of additional maintenance costs. The moment Java adds extension methods, this split can be revisited again.