BlockingObservable

[benjchristensen]

Move all blocking operators to BlockingObservable. This has breaking changes for anything using blocking operators ... part of the pursuit of establishing a clean API on our path to 1.0.

This is something I've been wanting to do for a while but got the push over the ledge via discussion at #270.

This strays from "match Rx.Net as closely as possible" but feels justified for the following reasons:

• Rx is primarily intended for asynchronous event handling and composition
• mixing blocking and non-blocking operators is confusing and leads to poor usage patterns
• mixing blocking operators (like take and takeLast is non-obvious)
• Rx.Net intends on deprecating (or has already) blocking operators as per Erik Meijer @headinthebox in this discussion: Blocking behaviour in RxJava #270 (comment)

I have removed all blocking operators from Observable and put them in BlockingObservable. I have left Observable.toBlockingObservable as a means of going from one to the other as it is an obvious communication of what is now being permitted.

While doing this I also cleaned up some odd API artifacts such as toObservable vs from and moved implementation specific code from rx.util into the internal package rx.operators where all code reserves the right to change at any time.

I intend on releasing this as version 0.9.

[cloudbees-pull-request-builder]

RxJava-pull-requests #144 FAILURE
Looks like there's a problem with this pull request

[cloudbees-pull-request-builder]

RxJava-pull-requests #145 SUCCESS
This pull request looks good

[benjchristensen]

Apparently another non-deterministic test testConcatUnsubscribe revealed by the always non-deterministically slow CloudBees ... second attempt succeeded, and it passes on my machine.

[benjchristensen]

I plan on merging this tomorrow morning (Thursday, May 16th Pacific time) if no strong reasons are given for not proceeding.

[benjchristensen]

No feedback to argue against proceeding so merging now...