Naming about reactive-streams-jvm

[jbrisbin]

I think we should also be sensitive to what's already being used in JDK 8 and if any of those types might potentially be re-used in a future JDK 9 implementation; the most important of those being:

public interface Consumer<T> {
    void accept(T t);
}

public interface Supplier<T> {
    T get();
}

public interface Function<T,V> {
    V apply(T t);
}

public interface Predicate<T> {
    boolean test(T t);
}

Some of the other names like Observable and Stream have different meanings already in different contexts (plain JDK, RxJava, etc...).

IMHO the only ones that we've talked about so far that don't seem pre-loaded based on previous associations seem to be Publisher and Subscriber.

[smaldini]

I like the current master (with request()) so I would vote -1 as I haven't seen appealing alternatives for now. My bias is I have started using these names too.

[patriknw]

I like Producer/Consumer, but Subscription doesn't fit in there, and they are already taken by JDK 8.
I vote on Publisher/Subscriber/Subscription.

[ktoso]

I also like Publisher/Subscriber/Subscription

Same reasons as Patrik + interfaces like Listener have a very concrete feel in Java land already - doesn't feel very right for our streams stuff (though I see / hear why it's tempting to call listen on a stream)

[benjchristensen]

I'm okay with Publisher/Subscriber/Subscription but am open to whatever the names need to be so as to achieve the goal of being very generic.

I imagine however that if the ultimate goal is to become part of the JDK, the relationship with the current Stream API is going to be tricky.

@DougLea What are your thoughts on this?

[DougLea]

About naming: if they were in a new package when standardized (say javax.reactive), then the names wouldn't be as constrained. But if incorporated in an existing package, they will need longer names to avoid clashes. For example, ReactiveSource, ReactiveSink, and ReactiveChannel.

(Also, apologies for being too swamped with other things lately to contribute much about other semantics issues.)

[benjchristensen]

Thanks @DougLea for the quick response, and no problem on being busy, many of us have similar problems. I need to spend some time on other things for a bit myself!

Do you think it's likely to use a separate package like javax.reactive or would you rather incorporate it into something like java.util.* similar to java.util.stream was?

What do you think the relationship with java.util.stream.Stream will be? Would the JDK be better having them related such as ReactiveStream or AsyncStream (even though I don't like that name)?

[DougLea]

Using an enclosing package seems like the best move. How about for now calling package org.reactiveStreams, and then migrating to either javax.reactiveStreams or java.util.concurrent.reactiveStreams, depending on how these things go.

With either of these, we could use the simplest termst: Source, SInk, Channel

[benjchristensen]

Generally in Java don't we avoid capitals or camel-case in package names?

[jbrisbin]

Maybe java.util.reactive or java.util.reactive.stream (or both)?

[benjchristensen]

I like either of those options from @jbrisbin

[rkuhn]

I’m also open to alternatives, but so far I have not seen anything which is better than Publisher/Subscription/Subscriber (since it is a metaphor from real life that just works so well).

Wrt. Java 8 Streams I would say that the only worry I would have is if we reused the Stream terminology, since I see those streams more on a DSL and end-user API level than what we are trying to achieve here. If Java 9 introduces streams that support lazy evolution, then we might just use those as one more language binding on the JVM for our underlying implementation of asynchronous boundaries—the focus of the java.util.stream package lies more on synchronous staged composition which is an orthogonal concern.

@normanmaurer @purplefox ?

[viktorklang]

Are we done here? (the bikeshed isn't even primed yet!)

[viktorklang]

Moving to close?
Ping @benjchristensen @jbrisbin @smaldini @mariusaeriksen @DougLea @jrudolph @normanmaurer @purplefox

[smaldini]

I am fine with the current naming 👍
Is that where we leaned to ?

[viktorklang]

@smaldini I'm also 👍 for current naming

[jbrisbin]

👍

[viktorklang]

@mariusaeriksen & @tmontgomery, wdys?

[tmontgomery]

I'm good. 👍

[mariusae]

LGTM

[benjchristensen]

I'm good with leaving the names as they currently are and closing this.

[viktorklang]

Great! Decided.