RxJava Code Review Part 2 (final + bonus thoughts)
RxJava has become a critical component of a huge amount of modern apps, we use it for everything: networking/other io, business logic, calculations and so on.
Two months ago I wrote RxJava Code Review Part 1.
I was hoping to write Part 2 in 1-2 weeks, so we are here 2 months ago…
// Always multiply your initial estimation by 3.14!
So, what I can say about RxJava now?
It's pretty good :)
As promised in Part 1, I've created issues and PRs during code review:
- PR #3142: Remove redundant final modifier from static method in Actions
- PR #3143: Fix for BackpressureUtils method javadoc
- PR #3144: Remove redundant cast in Exceptions
- PR #3147: Remove unnecessary static modifier
- Issue #3148: Leak of Subscriber in case of long blocking execution after unsubscribe()
- Issue #3295: Abstraction for Clock with DI via RxJavaPlugins
- PR #3361: Safer error handling in BlockingOperatorToFuture
- PR #3362: Fix synchronization on non-final field in BufferUntilSubscriber
- PR #3363: Remove unused private method from CachedObservable and make "state" final
- PR #3364: Possible multithreading bug fix in OnSubscribeAmb
- PR #3365: Make field final and remove unnecessary unboxing in OnSubscribeRedo.RetryWithPredicate
- PR #3370: Remove unused field updater from SubjectSubscriptionManager
Plus comments, hope RxJava developers and watchers are not tired of me :)
Also, I've gave a talk about RxJava on Yandex Mobile Camp in Moscow at the beginning of September.
And now I am slowly preparing slides and speech for the little talk about Rx in English!
Between Part 1 and Part 2, guys at Netflix and other RxJava commiters, mostly akarnokd, started working on RxJava v2.
- Good: RxJava v2 will be slightly better than v1 in terms of API (
- Bad: I am almost sure that we won't be able to use RxJava v2 on Android. RxJava v2 uses not only Java 8 lang features (Retrolamda can save our asses here) but also JDK 8 APIs (it will be very problematic to port all of them to Java 6…).
- Good: RxJava v1 is a release with long term support, so we will see features and fixes for several years! And I guess, mostly Android Developers will be those persons who will support v1 in future :)
You can check out RxJava v2 branch.
Also, what have been found is that RxJava heavily uses
volatile fields +
AtomicFieldUpdater (reflection) instead of just plain
AtomicLong, etc. Mostly because of lower memory consumption (you can have one
AtomicFieldUpdater and a lot of
The problem that I see with
AtomicFieldUpdater is reflection performance on Android :( Though it's not so critical and you don't need to worry too much about that. See this thread for more info.
RxJava is awesome, it has fantastic documentation http://reactivex.io, it saves you from tons of compilcated-concurrent-difficult code (for example, try to combine multiple async calls into one and handle errors without Rx) and makes life easier.
And it's written with performance and low memory consumption in mind!
This was Part 2, the end. Here is Part 1 with some code metrics and so on.
Be reactive, be happy, use Rx!