Abstraction for Clock with DI via RxJavaPlugins

[artem-zinnatullin]

Intro: in RxJava (for the Operators) time is related to a Scheduler that runs the code, and this is awesome (Schedulers.test() proves that).

But, at the moment RxJava's Schedulers use System.currentTimeMillis() as the source of the time to make some time-relative things work: delay(), window(), schedule(), schedulePeriodically(), Schedulers.test() and so on.

The problem with System.currentTimeMillis() is that it represents "wall clock" which can be changed by:

• By the user of the OS/device.
• By the OS itself: for example, your mobile devices sync wall clock with the carrier periodically, desktop and server OSes also do this.
• Leap second, half of the internet was not available because of Leap second problem this year, we can prevent this problem in our systems!

Such changes of wall clock may break the business logic of the applications (think about banking, security, apps and systems) and even crash them or create dead/live locks.

Proposal: Add Clock abstraction which will use System.currentTimeMillis() by default (no breaking changes) and ability for the users to inject their own implementation via RxJavaPlugins.

In Android we can use SystemClock.elapsedRealtime() as the source of linear, monotonic time in milliseconds. I guess, we will even be able to ship this via RxAndroid as a default option for RxJava on Android, or it's possible to do this via reflection directly in RxJava (though I am not a fan of reflection in RxJava).

See also #2943.

I can work on PR for this both for RxJava and RxAndroid if RxJava team will agree with this proposal.

CC all who interested in this, what is your opinion?

[akarnokd]

Do we have a desktop Java version of this SystemClock.elapsedRealtime?

[konmik]

We have System.nanoTime at both - Android and JRE.

[akarnokd]

System.nanoTime has much weaker guarantees, see this.

[konmik]

Weaker guarantees than what? There are no other nanosecond precision counters in Java. nanoTime has better guarantees than others just because it is nano. It is just slower sometimes.

[artem-zinnatullin]

@akarnokd

Do we have a desktop Java version of this SystemClock.elapsedRealtime?

Nope :( Some OSses give such APIs but it'll require JNI call, though one of the ideas of Clock abstraction is that you can inject your own implementation and do such JNI calls if it's really critical for your system.

• On Linux you can get monotonic time via clock_gettime():
• On Windows you can get monotonic time via GetTickCount64() or GetTickCount().
• On Mac OS getting monotonic time is tricky but possible: see this post on SO.

@konmik

Weaker guarantees than what? There are no other nanosecond precision counters in Java. nanoTime has better guarantees than others just because it is nano. It is just slower sometimes.

System.nanoTime() can depend on internal CPU timer (depends on JDK/JRE).

For example, in multi-CPU systems System.nanoTime() can give different results between CPUs, since RxJava actively used in backend systems like Netflix and multi-CPU servers are pretty usual — we can not use System.nanoTime() for Schedulers.

[sparty02]

To note, I think the spirit of this has been addressed in Java 8's Clock. If there is a need to support < 8, the Java 8 Date/Time refactor has been externally back ported via the ThreeTen project, which exposes a similar clock abstraction. cc @jodastephen. If there is a strong need to limit the dependencies, maybe it's still worth modeling after these abstractions.

[artem-zinnatullin]

Closing for now, #3467 looks good so far.