The reactive lifecycle constructs the platform used from RxJava — the Disposable and CompositeDisposable abstractions — are now implemented directly using JDK concurrency primitives. The platform never adopted the broader reactive stream model; it used RxJava solely for these two cleanup patterns. Rewriting them against the JDK removes the library from the core module dependency without changing any observable behaviour at call sites.
What changed
- Disposable. Represents a single resource or subscription that can be cancelled or released. The JDK-native implementation wraps an atomic flag and a cleanup callback, equivalent in contract to the RxJava original.
- CompositeDisposable. Holds a collection of disposables and cancels all of them on a single
dispose()call. The new implementation uses a thread-safe list to handle concurrent additions and a single atomic flag to prevent double-disposal. - Call-site compatibility. Both types implement the same interface contract as their RxJava counterparts. No call sites required changes — the substitution is a dependency-level swap, not an API change.
Why this matters
- Reduced dependency surface. RxJava is a large library with transitive dependencies. Removing it from the core module reduces the binary footprint and eliminates a category of version-conflict risk on downstream integrations.
- Explicit ownership. The lifecycle patterns the platform actually uses — cancel, group-cancel, is-disposed — are now defined within the codebase rather than inherited from an external contract whose scope the platform does not need.
The change is invisible to application developers; the dispose-and-cleanup patterns it supports are internal to the server runtime. The motivation is dependency hygiene: reducing the core module's external surface to what the platform genuinely needs.