Implement shorter toBlocking as shorter alias for toBlockingObservable.

[daschl]

Fixes #1220

[cloudbees-pull-request-builder]

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

[headinthebox]

I s this really causing you pain? Autocomplete will type the few extra characters for you, when reading code toBlockingObservable should stand out like a sore thumb. DANGER.

[daschl]

@headinthebox actually not for me, but for our users. 99% of them are on blocking-type applications and will need to call that often. Even in unit tests it is very long and doesn't help with readability.

So I'm all in for a shorter version.

[benjchristensen]

I think .toBlocking() still sufficiently signals what is going on. We don't need the Observable name everywhere, people already know it's an Observable.

Also, this is more similar to how we will likely someday implement .toParallel() which would return a ParallelObservable.

[headinthebox]

I wont block this ;-). Just want to make sure people understand that blocking defeats the purpose of Rx.

[benjchristensen]

Yes it certainly does ... but what I've found is that enabling an API with Rx is made far easier when we can give people who aren't ready to adopt async an easy way out. An API can always go from async to sync, but not sync to async, so anything that removes roadblocks to getting async APIs in place is helpful.

[benjchristensen]

I kind of wish we didn't have toBlockingObservable after this change, but that's a massive breaking changes for a lot of codebases, so I think we'll just live with the alias.

[benjchristensen]

Should we deprecate toBlockingObservable and delete in a release or two or keep them both forever?

[headinthebox]

I guess so; too many aliases indicate indecisiveness of the API designers ;-)

[benjchristensen]

Exactly.

[benjchristensen]

Done in #1233