RxJavaExtensions fills in the operators RxJava 4 does not ship

A companion library, because the core API cannot keep growing

RxJavaExtensions is described as the RxJava 4.x implementation of extra sources, operators and components, and ports of many 1.x companion libraries. That description contains the whole design. A reactive library's core API is a compatibility promise, so it cannot keep absorbing new operators without becoming a moving target, and the community's answer has always been to put the extras in a separate library. The second half of the description matters just as much: a lot of this code existed as companion projects for RxJava 1.x and was carried forward. For an adopter, that means two kinds of value in one artifact. Some of it is new work that fills a gap nobody in the core library would take, and some of it is familiar code that has been ported to the 4.x API, which is a different thing from writing it from scratch. The topics on the repository say the same thing in two words, extensions and rxjava, and the default branch is 4.x, so the 4.x implementation is the one that is being worked on.

The dependency is one line, and the coordinates carry the major version

The README gives the Gradle coordinates directly:

dependencies {
    implementation "com.github.akarnokd:rxjava4-extensions:4.0.0"
}

Two details in that line are worth reading carefully. The artifact name carries the major version, rxjava4-extensions rather than rxjava-extensions, so the 4.x line does not collide with the older coordinates on Maven Central, and the group is com.github.akarnokd, which is the GitHub-based group id used by the project. The documentation is published as Javadoc at the akarnokd.github.io site, and the README also points at Maven search for the group. For a team migrating from the 1.x era, the version in the artifact name is the point to check first, because the coordinate changes with it, and a build file that still points at the old name will resolve to the old line rather than failing loudly.

The maths operators exist to avoid reboxing primitives

The clearest piece of engineering in the library is the maths operators, and the README gives the reason. Although most of the operations can be performed with reduce, these operators have lower overhead as they cut out the reboxing of primitive intermediate values. The operations live in two classes, MathFlowable for Flowable sequences and MathObservable in Observable sequences, and the set is small and specific: averageDouble, averageFloat, max, min, sumDouble, sumFloat, sumInt and sumLong. The example shows how the operators are meant to be used, with the standard test harness asserting the result:

MathFlowable.averageDouble(Flowable.range(1, 10))
.test()
.assertResult(5.5);

This is the kind of thing that a core library will not add, because it is a performance specialisation rather than a missing capability, and because it needs a primitive-aware pipeline to be worth anything. It also means the library is not a general purpose second RxJava. It is a list of specific gaps, some of them narrow, and the maths classes are the most obviously justified of them.

Functional interfaces without throws Exception, and consumers up to nine arguments

The extra functional interfaces section targets two separate annoyances. The first is checked exceptions in callbacks. The library provides SimpleCallable, which is a Callable without throws Exception, and a family of PlainFunction, PlainBiFunction and PlainFunction3 through PlainFunction9 that are the same without throws Exception. The second is arity. There are Consumer3 through Consumer9, functional interfaces of consumers with three to nine type arguments, which exist to support the join patterns and the async-util work described in the same paragraph. Utility functions that support these interfaces are collected in the FunctionsEx class. The motivation for the whole group is stated in one line, support the join-patterns and async-util with functional interfaces of consumers with 3-9 type arguments and have functional interfaces of functions without the throws Exception. That is a fairly specific brief, and it tells you the library is not a general purpose utility drawer but a set of additions aimed at a particular style of reactive programming.

The operator catalogue is where the volume is

The features list is dominated by custom operators and transformers, and the names give a good sense of the gaps being filled. There are buffer variants, bufferWhile, bufferUntil and bufferSplit, and window equivalents, windowWhile, windowUntil and windowSplit. There are concurrency-shaped operators such as flatMapSync, flatMapAsync, mapAsync, filterAsync and switchFlatMap, plus switchOnFirst and flatMap on signal type for work that depends on the first emission. There are timing operators such as onBackpressureTimeout, intervalBackpressure, timeoutLast, timeoutLastAbsolute and debounceFirst, and error handling helpers such as errorJump, which restarts a sequence after a failure. Then there are valve, orderedMerge, spanout, mapFilter, repeat and repeatCallable, every, cacheLast, switchIfEmpty, expand, zipLatest, coalesce, indexOf, requestObserveOn, requestSample, observeOnDrop, observeOnLatest, generateAsync, partialCollect, flatMapDrop and flatMapLatest. For parallel sequences there is a separate set with sumX and orderedMerge. The debugging section is worth noting separately, with function tagging, protocol validation and multi-hook handlers, and the consumer helpers end the list with subscribeAutoDispose, which is the one most teams are likely to reach for.

Custom processors, subjects and schedulers

Beyond operators, the library ships components. There are specialised processors in the SoloProcessor, PerhapsProcessor and NonoProcessor family, and a set of work dispatching subjects and processors in UnicastWorkSubject, DispatchWorkSubject and DispatchWorkProcessor. MulticastProcessor is listed with a note that it was deprecated in 0.19.2, which tells you this library carries its own history rather than being a clean sheet. The FlowableProcessor utilities section is small, with wrap and refCount, and the custom schedulers come in three flavours: SharedScheduler, ParallelScheduler and BlockingScheduler. The blocking one in particular is the sort of operator that exists because the core library will not offer it, since blocking inside a reactive chain is normally a mistake but is sometimes exactly what a script needs. The special publisher implementations and the per-type consumer classes, FlowableConsumers, ObservableConsumers, SingleConsumers, MaybeConsumers and CompletableConsumers, round out the set.

An alpha line, a long gap, and an Apache licence

The release history explains the shape of the project. The 4.x line's newest tag is v4.0.0-alpha-19 from 2026-07-11, and before that come 3.1.1 from 2021-08-31 and 3.0.1 from 2020-08-20, so there is a gap of several years between the last 3.x release and the first 4.x tags. The repository is not archived and the last push was on 2026-10-22, so the 4.x work is still moving even though the tags are alpha. The licence is Apache-2.0, with the LICENSE file at the root, alongside a SECURITY.md. The build is Gradle, with build.gradle, settings.gradle, the wrapper scripts, a pmd.xml static analysis configuration and a config/ directory, and the CI badges in the README point at a Java CI with Gradle workflow, a codecov coverage report and an OpenSSF Scorecard badge. The build also carries a push.sh script, which suggests the maintainer publishes with a local script rather than only through the CI pipeline.

Editorial conclusion

Adopt RxJavaExtensions if you are on RxJava 4 and keep bumping into the same gaps: a maths operator that reboxes primitives, a functional interface that forces throws Exception, or a transformer that RxJava itself does not ship. Do not adopt the 4.x line in production without weighing the alpha, since the newest tag is v4.0.0-alpha-19 and the last stable 3.x release was 3.1.1 in 2021. Before you commit, check the Javadoc for the exact operator you need rather than assuming the 1.x name still applies, since this library is explicitly a port and the RxJava 4 API moved, and confirm the 4.0.0 artifact is the one your build resolves.

Frequently asked questions

Official sources

1. akarnokd/RxJavaExtensions on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases