v2 work-in-progress

[benjchristensen]

Since @akarnokd has started sprinting on v2 ... a place to discuss back-and-forth ...

[benjchristensen]

@akarnokd I'm pulling in the snapshot and starting to apply it to a project.

Things I still need to replace 1.x are:

• doOnSubscribe
• doOnUnsubscribe
• concatWith
• mergeWith
• publish()
• ConnectableObservable .connect
• TestSubscriber
• subscribe overloads (to use lambdas)

Are you working on any of these or have them close? Otherwise I'll start on some of them.

[benjchristensen]

The project I want to use v2 with is this: https://github.com/ReactiveSocket/reactivesocket-java

It uses Reactive Streams as the public API, and is very performance sensitive. Right now I'm only using RxJava v1 in the unit tests, and the operators/classes listed above are what I need before I can move from v1 to v2.

To use in the main code and replace the custom Publisher impls will require v2 proving it can be added without impacting performance.

We also can't go too much farther with v2 work without establishing how our unit and perf tests will be done.

[akarnokd]

These are available:

• publish()
• ConnectableObservable (except refCount())

I plan to do concatMap next in the morning. If you really need it, you can do mergeWith via merge, but I plan to implement a version that compacts chains of mergeWith calls.

The other operators you mentioned are lower priority for me and plan to leave them for now.

Otherwise, as of now 2.x contains:

• complete Scheduler API and Schedulers
• source operators (just, fromX, range, empty, error, never)
• map, flatMap, filter, merge, mergeDelayError
• take (untimed), skip (untimed), takeUntil
• observeOn, subscribeOn, unsubscribeOn
• all overloads of publish, cache, replay
• lift, compose, to
• any, all, count, single, elementAt, isEmpty
• toList, toSortedList

I plan to move the unit tests one by one after all operators have been implemented. As for the perf classes, I thought adding RxJava 1.0 as a perf dependency to gradle but don't know how (perfCompile ?). That way, comparative benchmarks can be established within 2.x.

[artem-zinnatullin]

@benjchristensen @akarnokd since RxJava v2 will be different from v1 in many aspects I want to ask: you still want to keep both Subscriber and Observer?

It adds some confusion for RxJava users that I know (and for me in past, but then I've found #792).

See:

• What is the difference between an Observer and a Subscriber?
• Observer and/or Subscriber?

Or if you still want to keep both of them can we please add more information and notice the difference between Observer and Subscriber in javadoc and make it more visible on reactivex.io? (there is a paragraph about Unsubscribing on the page about Observable)

[benjchristensen]

@artem-zinnatullin if more docs would help, perhaps you could help contribute them in https://github.com/ReactiveX/reactivex.github.io?

It's too early in 2.x to have the Observer/Subscriber details finalized, but I expect we'll still have a similar division. The org.reactivestreams.Subscriber represents the backpressure and unsubscribe capable consumer, while io.reactivex.Observer could be the simpler consumer that doesn't support unsubscribe, and requests Long.MAX_VALUE (the normal default for a synchronous consumer). This distinction still makes sense to me.

In 2.x however we should no longer need a concrete Subscribe with SafeSubscriber semantics or unsubscribe semantics on termination.

[benjchristensen]

@akarnokd thank you for the info

I plan to move the unit tests one by one after all operators have been implemented. As for the perf classes, I thought adding RxJava 1.0 as a perf dependency to gradle but don't know how (perfCompile ?). That way, comparative benchmarks can be established within 2.x.

Before moving the unit tests over, I want us to agree on what the base tests for each operator should be. The 1.x unit tests all organically happened over 2+ years and our experience with what should be expected on each operator changed dramatically over that time. Let's capture that experience and knowledge in a base test suite that each operator must pass. Additionally, each operator should pass the Reactive Streams TCK.

Once we have that, then I'm okay with us moving over other tests to assert specific operator behavior outside the standard Reactive Stream/ReactiveX semantics.

As for perf tests, that's an interesting idea to have 1.x as a dependency for comparisons. Yes, I think it would be perfCompile. Similar to unit tests, it would be good to have a base suite of perf tests for an operator.

[benjchristensen]

Here are the issues applicable to unit tests and perf:

• 2.0 Design: Performance Benchmarking 2.0 Design: Performance Benchmarking #2784
• 2.0 Design: Test Suite 2.0 Design: Test Suite #2783

[akarnokd]

@artem-zinnatullin In the current 2.x, Observer is an abstract class that by default requrests Long.MAX_VALUE but you can override this behavior and gives the ability to cancel. It resembles the 1.x Subscriber behavior as it is stateful. The added benefit to 2.x is that since it extends RS Subscriber, you can have your Observer subscribed to any Publisher, not just RxJava 2.x Observables.

@benjchristensen I don't know much about the RS TCK but it is a good opportunity for the community to submit PRs that uses it.

[akarnokd]

@benjchristensen All your requested methods/classes have been added to 2.x.

[benjchristensen]

I don't know much about the RS TCK but it is a good opportunity for the community to submit PRs that uses it.

Yes, or I'll get to it. My ask is that you don't start on the unit tests until we've agreed upon an approach.

All your requested methods/classes have been added to 2.x.

You're a machine! :-) Playing with them shortly ...

[artem-zinnatullin]

You're a machine! :-)

+100!

@benjchristensen @akarnokd thanks for explanation about Observer's & Subscriber's future. I'll think about better docs for v1 and I'll try to show the difference between them for the users on my talk about RxJava.