2.0 Design: Naming

[akarnokd]

Since we are aiming at Java 9 and j.u.c.Flow as the base API, we have the opportunity to use Java-native functional interfaces instead of our Func and Action interfaces, plus rename other components.

I propose the following changes:

• Observable -> Flowable
  • Plus: no more name conflict with j.u.Observable or RxJava 1.0's Observable
• XXXSubject -> XXXProcessor
• XXXSubscription -> XXXDisposable
• Func0 -> j.u.c.f.Supplier
• Func1 -> j.u.c.f.Function
• Func1<T, Boolean> -> j.u.c.f.Predicate
• Func2 -> j.u.c.f.BiFunction
• Func3..FuncN -> rx2.functions.TriFunction or rx2.functions.Function3 etc.
• Action0 -> Runnable
• Action1 -> j.u.c.f.Consumer
• Action2 -> j.u.c.f.BiConsumer
• Action3..ActionN -> rx2.functions.TriConsumer or rx2.functions.Consumer3 etc.

[benjchristensen]

I personally am not a fan of Flow or Flowable. The Observable type is part of the Reactive Extensions brand and domain knowledge, so I don't think it's good to move away from that name.

Similar with Subject. I think that can implement Processor but doesn't need to stop being a Subject.

RxJava/1 Subscription does indeed need to become Disposable.

The various Java 8 functions are a tricky one. I don't like how confusing they are. We named ours in a way that they sort correctly in docs, they are more descriptive, and we also support arities beyond 3.

I think we should first explore whether the Func* and Action* interfaces can just be refactored to implement those interfaces (with apply instead of call) for example. I'm not convinced of the value of using the java.util.function interfaces, particularly when we're targeting Java 8 where lambdas mean it should be rare to concretely implement one of them, it is just the shape of the lambda. We could move Action to Consumer but we retain Consumer0, Consumer1, Consumer2 etc. Same with Func.

• How would we deal with Func4-Func9 and Action4-Action9?
• What is the value of adopting the Java 8 types directly instead of just extending them?
• API design and discoverability is important. I find the Java 8 names to be highly non-discoverable.

[akarnokd]

Similar with Subject. I think that can implement Processor but doesn't need to stop being a Subject
I had to introduce ProcessorEx just to add our extra methods, so I guess Subject stays.

Java 8 functional interfaces indicate the purpose not just the shape, but it is a matter of taste. If lambdas are used, it doesn't really matter except when the user has some Runnable r = () -> { ... } instance already and still has to convert it to Action0. JIT will probably inline the call properly, but if the call site ends up being megamorphic, we'll still get an extra wrapper object. Defining Action0 on top of Runnable this way:

interface Action0 extends Runnable { default void run() { call(); } void call(); }

This helps if one wants to send an Action0 to a executor but not the other way around.

Still, there could be name conflicts between Func0/Action0 and the higher arity functions when compared to JDK types: Supplier.get vs Function.apply and Runnable.run vs Consumer.accept. By itself, Callable already has method name conflict with Supplier.

For discoverability, we may define Func0 on top of Supplier and so on, but the method naming will be inconsistent across arities.

One thing I'd like to emphasize is the use of Predicate instead of Func1<T, Boolean>. I've read somewhere that the latter boxing/unboxing is not always optimized away by HotSpot and we get a reference equality check everywhere instead of just a CPU flag test.

It is hard to decide: an independent set of FuncX, PredicateX and ActionX gives us more control, but RxJava 2.0 can be accused of having its own functional types instead of standard Java ones. Having such interfaces name their single method call would certainly help with stateful implementations (as it does in RxJava 1.0).

[benjchristensen]

I'm thinking about this right now ... wondering if Flowable is the right thing as opposed to Observable.

I still think this:

The Observable type is part of the Reactive Extensions brand and domain knowledge, so I don't think it's good to move away from that name.

However, what I'm wondering is whether we should have both Observable and Flowable. If we had both, Flowable would implemented ReactiveStreams Publisher and Observable would not.

-> Observable -> no backpressure -> hot data sources
-> Flowable -> backpressure -> cold data sources, or hot ones converted to Flowable with flow control strategy

Is this something we should consider and pursue?

[akarnokd]

The name conflict is a smaller issue compared to the re-learning of the entry class name and scrub all the historical knowledge. I don't believe there will be many that use both versions in the same project and those who switch have to revisit every use place due to the package/API changes anyway.

Let's stick to Observable

[benjchristensen]

What about different types to represent hot and cold?

[headinthebox]

-> Observable -> no backpressure -> hot data sources
-> Flowable -> backpressure -> cold data sources, or hot ones converted to Flowable with flow control strategy

That is what I have been proposing for a while, and what I am pursuing with RxMobile, since it only needs to deal with semi realtime hot streams that have no intrinsic support for back-pressure.

Semantically, conceptually, and scenario-wise Observable and Flowable are very different. In the current RxJava the lines have gotten blurred. This is a perfect place where having two types makes the distinction crystal clear. You are dealing with one kind of stream, and you need to take care of certain constraints, or you are dealing with a whole other kind of streams and you have different concerns.

It is not Flowable either or Observable, but Observable and also Flowable.

Like any collection, both types support the same kind of operators like map, flatMap, filter, ... That is where you re-use your knowledge.

KISS FTW

[benjchristensen]

Been thinking more about this. I conceptually like the idea of them being separate, and Observable not supporting backpressure, but I don't know how to solve the flatMap issue without an unbounded buffer, and I really don't think we should have an unbounded buffer unless a developer asks for it.

In Rx.Net merge/flatMap doesn't have an unbounded buffer – because it blocks emissions when contention occurs by synchronizing (at least as of a couple years ago).

In RxJava, where we're targeting environments with event loops like Netty, merge can't be implemented using synchronization. To be non-blocking merge must allow asynchronous enqueuing of items when contention occurs. This means either (a) unbounded buffers, or (b) bounded buffers and backpressure.

@headinthebox I know that you argue that unbounded buffers are not always bad, and I agree that they aren't always bad. I think they're just fine when a developer opts in to it. I do however think they are bad when hidden, and don't feel comfortable reverting the decisions of 1.x to allow hidden unbounded buffers again.

So, "KISS FTW" sounds nice, but it doesn't address the real issue of not-simple-to-debug silent latency and memory bloat of unbounded buffers. I have experienced this with RxJava 0.x pre-backpressure in production systems.

So, if we do have an Observable without backpressure, how do we address merge/flatMap such that we don't have an unbounded buffer?

[headinthebox]

Let me state upfront that I do not understand why Netty excludes using synchronization, but that is my total ignorance on how Netty works.

However, I think that you can (roughly) achieve the same effect as non-blocking merge by doing an observeOn with the trampoline scheduler afterwards (if you squint at the queue draining code you will see it looks very much like a trampoline).

If that is true, then the use of a buffer becomes explicit due to the observeOn and it obvious in your code that you have to be careful, and no worse than when you use onBackPressureBuffer.

(BTW with async code there is no such thing as "simple-to-debug" ;-)

[benjchristensen]

I do not understand why Netty excludes using synchronization

It's not just Netty. Anything using event loops, including Schedulers.computation(), Aeron, CouchBase, most if not all memcached clients I'm aware of, Akka, and virtually anything else using NIO.

Synchronization of 2 event loops together would result in 1 thread being blocked. That is an absolute no for RxJava to cause.

observeOn

I focused on merge/flatMap, butobserveOnandzipare the other 2 major operators that have unbounded buffers and are problems.mergecould indeed be implemented likeobserveOn`, but that again is an unbounded buffer without backpressure.

(BTW with async code there is no such thing as "simple-to-debug" ;-)

There are gradients of "simplicity", it's not black-or-white. I'd rather encapsulate as much complexity in the implementation as possible so operating it is simpler. I'd also rather require a little more thought at time of creating an Observable than when consuming it or during system operation.

I think the biggest mistake in RxJava v1 after adding backpressure was continuing to let the raw Observable.create be the primary way of creating an Observable. It gave all the power tools without guiding towards the common "hot" and "cold" usage scenarios.

Unless we don't offer flatMap/merge/zip/observeOn operators (which is unlikely), I am not comfortable having an Observable type with unbounded buffers hidden within operators. Thus, it leads me back to having a single type (either Observable or Flowable), and a createHot method (or something with a similar name) that requires a choice of what to do if the consumer is too slow. By default it is to fail, but other strategies can be drop, sample, throttle, buffer (bounded or unbounded), etc.

cc @stevegury and @tmontgomery who I consulted with on this topic in case either of them want to weigh in.

[benjchristensen]

I've opened a new issue to move this conversation about bounded/unbounded: #3213

[headinthebox]

If this is so important for you, then we should only have Flowable and always do back pressure, and not call it Observable anymore.

[I remain of the opinion that it is absolutely OK that it is the developer's responsibility to make sure their app runs under the required memory & time constrains, and that given we are in a Turing complete world, unbounded buffers are no different than any other unbounded use of memory, or time. But obviously I am alone in this viewpoint, so will happily surrender to the majority vote.]

[benjchristensen]

@headinthebox Is this perspective driven by theoretical purity about Observable being "purely reactive", or is there a functional or usability concern with the RxJava v1 Observable type that drives this?