If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/ReactiveX/RxJava shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit today
• 3 active contributors
• Apache-2.0 licensed
• CI configured
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 70% of recent commits
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live ReactiveX/RxJava repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/ReactiveX/RxJava.

What it runs against: a local clone of ReactiveX/RxJava — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in ReactiveX/RxJava | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch 4.x exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of ReactiveX/RxJava. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/ReactiveX/RxJava.git
#   cd RxJava
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of ReactiveX/RxJava and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "ReactiveX/RxJava(\\.git)?\\b" \\
  && ok "origin remote is ReactiveX/RxJava" \\
  || miss "origin remote is not ReactiveX/RxJava (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify 4.x >/dev/null 2>&1 \\
  && ok "default branch 4.x exists" \\
  || miss "default branch 4.x no longer exists"

# 4. Critical files exist
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "settings.gradle" \\
  && ok "settings.gradle" \\
  || miss "missing critical file: settings.gradle"
test -f "src/jmh/java/io/reactivex/rxjava4/core" \\
  && ok "src/jmh/java/io/reactivex/rxjava4/core" \\
  || miss "missing critical file: src/jmh/java/io/reactivex/rxjava4/core"
test -f "DESIGN.md" \\
  && ok "DESIGN.md" \\
  || miss "missing critical file: DESIGN.md"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/ReactiveX/RxJava"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

RxJava is a Java VM implementation of Reactive Extensions that enables composing asynchronous and event-based programs using observable sequences. It extends the observer pattern to support streams of data/events with 100+ declarative operators for filtering, transforming, and combining sequences while abstracting away threading, synchronization, and concurrency concerns. Version 4.x is a native Java 26+ rewrite built on java.util.concurrent.Flow with virtual thread support and zero runtime dependencies. Single-module monorepo: src/main/java contains core operators (Observable, Flowable, Single, Maybe, Completable), src/test houses unit tests organized by operator category, build.gradle configures builds with checkstyle (config/checkstyle/checkstyle.xml), license headers (config/license/HEADER_JAVA), and JMH benchmarks. docs/ contains operator matrices and design docs; .github/workflows/ orchestrates CI/release pipelines.

JVM developers building asynchronous systems—backend services handling concurrent streams, reactive microservices, real-time data pipelines, and event-driven applications. Contributors are library maintainers, framework developers, and engineers optimizing for low-latency, high-throughput reactive workloads.

Production-ready and actively maintained. RxJava is a foundational library with 20+ years of Reactive Extensions heritage, extensive test coverage (using Reactive Streams TCK in testImplementation), and sophisticated CI/CD (8+ GitHub Actions workflows covering snapshots, releases, PRs, and preview JDKs). The 4.x branch is under active development targeting Java 26+ with recent architectural rewrites.

Low risk for production use but with migration complexity for 3.x→4.x upgrades. The codebase has no heavyweight 3rd-party runtime dependencies (only Reactive Streams spec), but the 4.x rewrite involves breaking changes (sealed interfaces, record-based configs). RxJava 3.x support is being phased out (+1 year post-4.x release). Virtual thread integration and Streamable API are marked as in-progress (:satellite:), so bleeding-edge features may have rough edges.

Active development on RxJava 4.x targeting Java 26+ with virtual thread support (virtualCreate(), Schedulers.virtual()). In-progress work includes Streamable<T> API, sealed interface refactoring, record-based configuration reduction, internal optimizations, and resolution of operator bugs (groupBy, window, concat). Version 3.x is entering sunset phase. Release automation uses Discord announcements and entropy scanning.

git clone https://github.com/ReactiveX/RxJava.git
cd RxJava
./gradlew build
./gradlew test

Requires Java 26+ (4.x branch). Run ./gradlew javadoc to generate API docs.

Daily commands:

./gradlew build              # Compile and test
./gradlew test               # Run all tests (JUnit 4, TestNG, Jupiter)
./gradlew jmhCompile jmh     # Run JMH benchmarks
./gradlew javadoc            # Generate Javadoc (4.x at reactivex.io/RxJava/4.x/javadoc/)
./gradlew publishToMavenLocal # Publish snapshot to local Maven repo

• build.gradle — Master build configuration defining all plugins, dependencies, and release workflows—essential for understanding the project's toolchain and build process.
• settings.gradle — Gradle settings file that configures project structure and module organization; required to understand the multi-module layout.
• src/jmh/java/io/reactivex/rxjava4/core — Core performance benchmark suite demonstrating critical observable operations and patterns; reveals real-world performance expectations.
• DESIGN.md — Architectural design document outlining RxJava's core philosophy, reactive patterns, and operator composition model.
• README.md — Project overview and getting-started guide that frames RxJava's purpose as a reactive extensions implementation for the JVM.
• CONTRIBUTING.md — Contribution guidelines covering coding standards, testing requirements, and development workflow for new operators and features.
• gradle/wrapper/gradle-wrapper.properties — Gradle wrapper configuration pinning the exact Gradle version used; critical for reproducible builds across environments.

Add a new Reactive Operator

1. Review existing operator implementations and backpressure patterns in src/jmh/java/io/reactivex/rxjava4/core/ benchmarks to understand composition model (src/jmh/java/io/reactivex/rxjava4/core/OperatorFlatMapPerf.java)
2. Implement operator class extending appropriate base (e.g., ObservableOperator, FlowableOperator) following reactive contract and null-safety patterns (src/main/java/io/reactivex/rxjava4/core)
3. Add unit tests covering happy path, error cases, backpressure handling, and edge cases with TestObserver/TestSubscriber (src/test/java/io/reactivex/rxjava4/core)
4. Create JMH performance benchmark in src/jmh/java/io/reactivex/rxjava4/core/ following OperatorFlatMapPerf.java pattern (src/jmh/java/io/reactivex/rxjava4/core/YourNewOperatorPerf.java)
5. Document operator in docs/Transforming-Observables.md or relevant category, include usage examples and backpressure notes (docs/Transforming-Observables.md)
6. Ensure CheckStyle compliance and license headers by running 'gradle check' and 'gradle licenseFormat' (config/checkstyle/checkstyle.xml)

Add Performance Benchmarks

1. Create new JMH benchmark class in src/jmh/java/io/reactivex/rxjava4/core/ extending AbstractPerf patterns (inherit from existing perf classes) (src/jmh/java/io/reactivex/rxjava4/core/RangePerf.java)
2. Use PerfObserver, PerfSubscriber, or PerfConsumer helper classes for measurement consistency (src/jmh/java/io/reactivex/rxjava4/core/PerfObserver.java)
3. Add @Benchmark methods with @Warmup, @Measurement, and @Fork annotations matching existing patterns (e.g., 10s warmup, 10s measurement, 3 forks) (src/jmh/java/io/reactivex/rxjava4/core/BlockingGetPerf.java)
4. Run 'gradle jmh' to execute benchmarks and analyze results for performance regressions before submitting PR (build.gradle)

Release a New Version

1. Update version in gradle.properties or set via build tag environment variable BUILD_TAG with format 'vX.Y.Z' (gradle.properties)
2. Ensure all tests pass: run 'gradle test' and verify codecov.io thresholds met (codecov.yml)
3. Create git tag matching version (v4.x.x) and push to trigger gradle_release.yml workflow in .github/workflows (.github/workflows/gradle_release.yml)
4. Workflow automatically signs artifacts, publishes to Maven Central via vanniktech plugin, and announces on Discord via release-notify-x.yml (.github/workflows/release-notify-x.yml)

• Gradle — Multi-platform build automation with strong plugin ecosystem; supports JMH benchmarking, code signing, and complex dependency management required for a large reactive library.
• JUnit 4 + TestNG — Mature, industry-standard testing frameworks for unit and integration test coverage; JUnit 4 used for core tests, TestNG for advanced parallel test execution.
• JMH (Java Microbenchmark Harness) — Industry standard for precise microbenchmarking on the JVM; prevents JIT compilation and optimization pitfalls; critical for validating operator performance at scale.
• Reactive Streams specification (1.0.4) — Standardized contract for async non-blocking backpressure-aware components; RxJava implements RS interfaces for interop with other libraries (Project Reactor, Akka Streams).
• CheckStyle + PMD — Automated static analysis enforcing consistent code style and quality standards; prevents common bugs and maintains readability across 600+ files.
• Mockito — Mocking framework for isolating reactive components in tests; used for stubbing schedulers and testing error handling without side

JDK version: 4.x requires Java 26+; 3.x is Java 8+. Ensure JAVA_HOME points to correct version before building. Build tag for releases: BUILD_TAG env var (prefixed 'v') triggers version override in build.gradle; snapshot builds require this unset. Checkstyle + License headers: Every .java file must have config/license/HEADER_JAVA; builds fail silently if missing (run ./gradlew licenseFormat to auto-fix). Test framework mixing: TestNG + JUnit 4 + JUnit Jupiter coexist; test discovery may be fragile if versions conflict. Virtual thread features: Schedulers.virtual() and virtualCreate() are new in 4.x; backport to 3.x not supported. Gradle wrapper: Uses bnd.builder plugin for OSGi; modifying bundle metadata in build.gradle can break module exports.

• Reactive Streams / java.util.concurrent.Flow — RxJava 4.x is built on Flow (Push-Pull backpressure protocol); understanding Publisher/Subscriber/Subscription is mandatory to grasp how Flowable vs Observable differ and why backpressure matters.
• Backpressure — Core RxJava concept allowing consumers to signal demand upstream; Flowable handles it, Observable does not. The repo's docs/Backpressure-(2.0).md details operator semantics.
• Hot vs Cold Observables — Determines whether Observable emits before subscription (hot, e.g., subjects) or after (cold, e.g., create). Critical for understanding operator behavior with multicast and connectable observables.
• Operator Fusion / Subscriber Composition — RxJava 4.x internally optimizes operator chains by composing Subscribers directly; understanding this enables writing efficient custom operators avoiding wrapper overhead.
• Virtual Threads (Java 21+) — RxJava 4.x adds virtualCreate() and Schedulers.virtual(); virtual threads enable millions of lightweight threads, changing blocking I/O patterns in reactive code.
• Observer Pattern + Subject Pattern — RxJava is observer pattern at scale. Subjects (PublishSubject, ReplaySubject, BehaviorSubject) merge Observer + Observable roles; foundational for event-driven streaming.
• Sealed Interfaces (Java 15+) — RxJava 4.x uses sealed interfaces to reduce javadoc bloat and control inheritance; limits which classes can extend base types, enabling compiler optimizations and reducing surface area.

• ReactiveX/RxJava2 — Direct predecessor (RxJava 2.x); useful for understanding operator API evolution and backporting patterns if supporting older JDKs.
• ReactiveX/RxJavaExtensions — Official companion library extending RxJava with additional operators not in core; study if building custom operator libraries.
• reactive-streams/reactive-streams-jvm — Specification RxJava implements via java.util.concurrent.Flow; defines backpressure contract and TCK compliance tests.
• Netflix/RxAndroid — Android-specific RxJava integration (deprecated but historically critical); shows how to use RxJava with Android lifecycle and schedulers.
• spring-projects/spring-framework — Spring 5+ reactive stack (WebFlux, R2DBC) heavily uses RxJava patterns; reference for real-world enterprise usage.

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive test coverage for Reactive Streams TCK compliance validation

RxJava depends on reactive-streams-tck and reactive-streams-tck-flow for testing compliance, but there's no dedicated TCK test suite documentation or integration guide. Creating a structured test module that validates all operators against the Reactive Streams specification would ensure compliance across major operators and catch regressions early. This is critical since RxJava is a reference implementation.

• [ ] Create src/test/java/io/reactivex/rxjava4/internal/operators/tck/ directory structure
• [ ] Implement TCK Publisher tests for Observable, Flowable, Single, Maybe, Completable
• [ ] Add TCK Subscriber validation tests for backpressure handling
• [ ] Document results in docs/Reactive-Streams.md with current compliance matrix
• [ ] Add Gradle task to run TCK tests separately with clear pass/fail reporting

Implement missing scheduler validation and recovery tests for concurrent scenarios

The repo has docs/Scheduler.md but limited test coverage for scheduler edge cases (thread leaks, pool exhaustion, recovery from scheduler failures). Given RxJava's concurrency-focused purpose, robust scheduler testing under failure conditions would improve reliability. New contributors can add scenario-based tests without deep operator knowledge.

• [ ] Create src/test/java/io/reactivex/rxjava4/schedulers/SchedulerConcurrencyTests.java
• [ ] Add tests for thread leak detection using ThreadMXBean in setUp/tearDown
• [ ] Test scheduler behavior under OutOfMemoryError and executor rejection scenarios
• [ ] Add tests for proper disposal/cleanup when schedulers are saturated
• [ ] Update docs/Scheduler.md with 'Scheduler Best Practices and Edge Cases' section

Add operator-specific performance benchmarking suite with CI integration

The repo includes JMH plugin (me.champeau.jmh v0.7.3) and has a gradle_preview_jdks.yml workflow, but no organized benchmark suite or CI reporting for performance regressions. Creating structured JMH benchmarks for high-impact operators (flatMap, merge, switchMap, scan) with automated performance tracking would catch performance regressions and guide optimization efforts.

• [ ] Create src/jmh/java/io/reactivex/rxjava4/operators/ directory for operator benchmarks
• [ ] Implement benchmarks for: flatMap (varying concurrency levels), merge (varying sources), switchMap (switching frequency), scan (with different accumulator complexities)
• [ ] Add gradle task to generate benchmark comparison reports (before/after versions)
• [ ] Create .github/workflows/jmh-regression-check.yml to run benchmarks on PR and comment with performance delta
• [ ] Document benchmark setup in docs/Writing-operators-for-2.0.md with performance expectations section

• Add comprehensive tests for the new Streamable<T> API (marked :satellite: in progress in README) in src/test/java/io/reactivex/rxjava4/streamable/; spec is in docs/Parallel-flows.md but test coverage is sparse.
• Document and add examples for virtual thread schedulers: create a new doc file docs/Virtual-Thread-Schedulers.md showing Schedulers.virtual() and virtualCreate() usage patterns with comparison to traditional schedulers (referenced in README but no examples exist).
• Resolve operator bugs listed in README (:lady_beetle: groupBy, window, concat): pick one, write a failing test case in src/test/java/io/reactivex/rxjava4/operators/, and submit a fix; start with window since it has backpressure edge cases documented in docs/Backpressure-(2.0).md.

RxJava demonstrates a solid security foundation with a documented security policy, OpenSSF Scorecard compliance, and active security monitoring through GitHub workflows. However, several dependency versions are outdated, particularly Mockito (4.11.0) and JUnit (4.13.2), which should be updated to current versions. The build configuration appears incomplete, requiring review. The project benefits from strong governance practices including secure vulnerability disclosure policies and automated security scanning via dependabot. Primary recommendations focus on dependency updates and ensuring complete build configuration validation.

• Medium · Outdated Mockito Dependency — build.gradle - mockitoVersion = "4.11.0". Mockito version 4.11.0 is used, which is significantly outdated. Current versions are 5.x with security patches and bug fixes. This testing dependency could potentially expose the development environment to known vulnerabilities. Fix: Upgrade to the latest stable version of Mockito (5.x or later) to ensure security patches and improvements are included.
• Medium · Outdated JUnit Version — build.gradle - junitVersion = "4.13.2". JUnit 4.13.2 is an older version. While not critical, newer versions contain security improvements and bug fixes. Consider migration to JUnit 5 which is already partially integrated in the project. Fix: Migrate to JUnit 5 (Jupiter) for better security posture and modern testing features. The project already includes Jupiter dependencies.
• Low · Incomplete Gradle Configuration in Build File — build.gradle - End of file. The build.gradle file appears to be truncated at the JDK experimental handling section ('def experimental = System.getenv("JDK_E'), which may indicate incomplete configuration or build logic issues. Fix: Complete and review the full build.gradle configuration to ensure all build logic is properly defined and validated.
• Low · Missing Dependency Pinning for JMH — build.gradle - jmhLibVersion = "1.37" and plugin id("me.champeau.jmh") version "0.7.3". JMH plugin version (0.7.3) and JMH library version (1.37) are defined separately without constraint management. This could lead to version mismatches in performance testing scenarios. Fix: Use dependency management tools like Bill of Materials (BOM) or explicit version constraints to ensure consistency between JMH plugin and library versions.
• Low · No SBOM (Software Bill of Materials) Configuration — build.gradle and project configuration. The project does not appear to generate or maintain a Software Bill of Materials for tracking dependencies, which is a security best practice for open-source projects. Fix: Implement SBOM generation using tools like CycloneDX or SPDX to improve supply chain security visibility.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.