RxJava: Reactive Extensions for the JVM

What is RxJava

RxJava is a Java VM library implementing ReactiveX, letting you compose async, event-based programs as observable sequences instead of chains of callbacks. It extends the observer pattern with operators — map, filter, flatMap, and dozens more — that transform, combine, and schedule data streams declaratively while RxJava handles thread-safety underneath. It ships as a plain JVM dependency, no separate framework required.

Core reactive types and operators

• ✓Flowable and Observable model 0..N item streams; only Flowable adds Reactive-Streams-compatible backpressure, while Observable stays unbounded for short, GUI-style sequences.
• ✓Single, Maybe, and Completable cover the single-value and no-value cases — exactly one item or error, zero-or-one item, or a bare completion/error signal — without forcing backpressure onto flows that don't need it.
• ✓Schedulers replace raw threads with a swappable abstraction.
• ✓computation() runs CPU-bound work, cached() runs blocking I/O (replacing the deprecated io()), and the new virtual() runs blocking work on virtual threads instead of native OS threads.
• ✓Operators like flatMap, concatMap, and concatMapEager compose sequences declaratively, including parallel processing via Flowable.parallel() and ParallelFlowable.
• ✓A documented three-phase lifecycle — assembly time, subscription time, runtime — separates building a pipeline from running it, which is why deferred sources like Single.defer() matter for values computed after assembly.
• ✓The 4.x line adds a new Streamable<T> type built on virtual blocking and CompletionStage state machines, marked in the README as still in progress.

Common RxJava use cases

• •Running a blocking computation or network call on a background thread with subscribeOn() and delivering the result on a UI or single-threaded scheduler with observeOn().
• •Fanning a source flow out into per-item async calls with flatMap and merging the results back into one stream, useful for calling a second service per item returned by a first service.
• •Modeling event-driven UI or GUI interactions as Observable sequences on Android or Swing/JavaFX schedulers rather than raw listener callbacks.
• •Chaining dependent async steps (call A, then use its result to call B, then C) as a flatMap pipeline instead of nested callback handlers.

Alternatives to RxJava

Frequently asked questions

The problem it solves

Coordinating multiple asynchronous operations in Java — a network call that triggers another network call, a UI update that has to wait for a background computation, a stream of events that needs debouncing — usually degenerates into nested callbacks, manually managed thread pools, and ad hoc synchronization that's hard to test. RxJava replaces that with a small set of base types (Flowable, Observable, Single, Maybe, Completable) and Schedulers that abstract the thread underneath, so you describe what should happen to the data instead of wiring executors and locks by hand.

How to install / try

Add RxJava 4 as a Gradle dependency: implementation "io.reactivex.rxjava4:rxjava:4.x.y", replacing x.y with the actual version numbers (Maven users add the equivalent io.reactivex.rxjava4:rxjava coordinate). There's no third-party runtime library required beyond that, per the README. Note that 4.x moves the package to io.reactivex.rxjava4, so it isn't a drop-in swap for a project already pinned to RxJava 3's io.reactivex.rxjava3 packages.

How to use

A minimal RxJava program looks like: Flowable.just("Hello world").subscribe(System.out::println); — RxJava 4's base classes live under io.reactivex.rxjava4.core, so imports change from earlier major versions. From there, most real code follows the pattern in the README's background-computation example: run blocking work with .subscribeOn(Schedulers.cached()) (the replacement for the deprecated Schedulers.io()) and deliver results on another thread with .observeOn(). Because pipelines are built at "assembly time" and only start moving data once you call subscribe(), a value like Single.just(...) placed inside a chain can be evaluated too early — the README's fix is Single.defer(...) or Single.fromCallable(...) to postpone evaluation until runtime.

Who should try it — and who should skip

Reach for RxJava if you're on the JVM and already juggling more than one asynchronous source — background computation plus network calls plus UI updates — and want a single vocabulary (operators, Schedulers) to coordinate them instead of nested callbacks. Skip it for a single async call or two; CompletableFuture or plain coroutines/Structured Concurrency in modern Java cover that without the operator-chain learning curve. Teams mid-migration from RxJava 3 should also weigh the package rename in 4.x (io.reactivex.rxjava3 to io.reactivex.rxjava4) before committing, since it isn't a drop-in upgrade.

Related repositories