RxJava 4.x: alpha releases, backpressure types, and a new package root

Three alphas, and a 4.0.0 dated for the end of 2026

The release history contains nothing but prerelease artifacts. The three most recent tags are v4.0.0-alpha-21 dated 2026-08-05, v4.0.0-alpha-20 dated 2026-07-21, and v4.0.0-alpha-19 dated 2026-07-11, and no stable 4.0.0 has been published. The project commits to a date for it anyway, with a roadmap line reading 4.0.0 release 2026.11.30 tracked on a milestone. The 4.x branch is the default branch and was last pushed on 2026-09-28, so this is a line under construction rather than a parked one. What the library cannot yet offer is a version you can name and sit on. The setup instruction is to declare a coordinate with placeholders and then replace x and y with the latest version numbers, which hands the version decision to whoever builds your project:

implementation "io.reactivex.rxjava4:rxjava:4.x.y"

Pin it and you are watching an alpha series, and nothing in the release history states a compatibility guarantee between one alpha and the next.

Flowable against Observable is a backpressure decision that is awkward to undo

The base types divide along one axis: whether a step can say how many items it is ready to accept.

source.operator1().operator2().operator3().subscribe(consumer);

source.flatMap(value -> source.operator1().operator2().operator3());

Flowable is 0 .. N flows and supports Reactive-Streams and backpressure. Observable is also 0 .. N but carries no backpressure, and the project places it on short sequences and GUI interactions. Single is exactly one item or an error, Completable is completion or error with no items, and Maybe is no items, exactly one item, or an error. Those three are documented as neither supporting nor needing backpressure, on the reasoning that there is always room to hold one item temporarily. That reasoning holds only for single-item types. A chain built on Observable has no way to say it is full, so a fast producer and a slow consumer meet as memory growth or as lost data, which the project names as increased memory usage from temporary buffering or the need for skipping and dropping. Recovering from that means changing the type, not adding an operator.

Streamable blocks on purpose, which is why it leans on virtual threads

Streamable is the one type whose flow control is not an operator you attach. It is described as 0 .. N flows based on virtual blocking and CompletionStage-based state machines with native backpressure, and the reasoning is given outright: since 4.0.0, producers and consumers have to wait for each other to hand over data, so backpressure falls out of the handover instead of being negotiated. Waiting is blocking, and that is exactly why the type is built to work with virtual threaded ExecutorServices and the new Schedulers.virtual() scheduler. The same roadmap entry lists Streamable as in progress, which is the honest signal that its surface is still moving. Two things follow. First, the design trades non-blocking code for blocking code, so the runtime underneath has to make blocking cheap, and the 4.x additions virtualCreate(), virtualTransform(), and Schedulers.virtual() are what make that trade available. Second, a type the project itself marks in progress is a poor foundation to re-export from your own API today.

Android support is a condition, not a support matrix

The JVM story is stated plainly and the Android story is stated as a condition. The roadmap carries a single line about Android: compatibility depends on your API level and what desugaring is available. The project publishes no table of what works at which API level, no stated minimum, and no enumeration of the desugaring steps involved, so the sentence functions as a warning rather than a compatibility statement. For a reader on Android the cost of finding out is empirical: you build, and you discover which parts of the library your device or your minSdk cannot take. This carries more weight on 4.x than it did on 3.x, because the same roadmap describes the line as a native Java 26 implementation with no third-party library required at runtime, and a native target is precisely the kind that leans on language and API features a mobile runtime may not ship. The project hands you the condition and leaves the threshold to you. Any decision to adopt 4.x on Android has to start with your own desugaring configuration, not with the library's documentation.

The 4.x package root is io.reactivex.rxjava4, so upgrading touches every import

RxJava 4 components now live under io.reactivex.rxjava4, and the base classes and interfaces live under io.reactivex.rxjava4.core. That is a change to the package root rather than a version number, and the project's own Hello World reflects it:

package rxjava.examples;

import io.reactivex.rxjava4.core.*;

public class HelloWorld {
    public static void main(String[] args) {
        Flowable.just("Hello world").subscribe(System.out::println);
    }
}

Alongside the namespace change there is a stated support window: 3.x support will be toned down in the coming months and will be offered for one more year after the official 4.x release, which against the 2026.11.30 target places the end of 3.x in the same general period as 4.0.0 itself. What the project does not spell out is the port. No compatibility shim is named, no list of renamed or removed operators is given, and no mapping from 3.x base types to 4.x ones appears beyond the new import root. A team on 3.x is left to work out the migration by reading the 4.x Javadoc alongside its own call sites.

Assembly is inert, so a chain nobody subscribes to does nothing at all

Operators are applied at assembly time, and the project is explicit that nothing has happened yet:

Flowable<Integer> flow = Flowable.range(1, 5)
.map(v -> v * v)
.filter(v -> v % 3 == 0)
;

At that point the data is not flowing and no side effects are happening. Subscription is a separate and later state. The consequence is a class of mistake the type system will not catch for you. A chain put together during object construction, inside a dependency injection provider, or in a field initializer reads like work in the source and performs none at runtime, and if nothing ever subscribes to it the chain is simply inert, with no exception and no log line. Assembly is also not a point at which a sequence can be treated as a value, because the operators you attached have deferred everything to a subscriber that does not exist yet. Since the documentation treats assembly and subscription as two distinct named states, the moment a chain starts doing anything is something you have to go and find rather than something the type records.

No runtime dependency is the win, and the Java 27 footnote is the limit

The 4.x feature list pairs a native Java 26 implementation with no third-party library required at runtime, JPMS and OSGi support still intact, and a java.util.concurrent.Flow-based implementation. The footnote under the list marks the ceiling the project is working against: Java 27 has no language or API enhancements available to use, because Structured Concurrency remained a preview. For a reader, the native rewrite means the dependency you declare pulls in nothing transitive, so there is no extra artifact to shade, exclude, or audit on a server deployment, and module and OSGi metadata stay where they were, which matters where the classpath is resolved strictly. What it does not remove is the Android desugaring question, where having no third-party runtime library counts for less once you count the language features being relied on. The line also still carries a checklist rather than a finished contract: record-based configurations, internal optimizations, scoped variables, and the possible inclusion of second and third party operators are all listed as in progress or as possibilities.

Editorial conclusion

RxJava 4.x is the line to evaluate if you are starting fresh on the JVM, since it requires no third-party library at runtime and keeps JPMS and OSGi support intact, but it is not yet a dependency you can name and hold still: the published artifacts are alphas and 4.0.0 is dated 2026.11.30. On Android, settle the API level and desugaring question against your own minSdk first. On 3.x, treat the year offered after the official 4.x release as the deadline, and plan for a package root change, since 4.x components now live under io.reactivex.rxjava4 with the base types in io.reactivex.rxjava4.core, which is a rewrite of imports rather than a version bump.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes