[concurrency-interest] jdk9 Candidate classes Flow and SubmissionPublisher

Doug Lea dl at cs.oswego.edu
Sat Jan 17 10:48:57 EST 2015

On 01/17/2015 06:44 AM, Remi Forax wrote:

>> Anything that I missed to reply to?
> Why the reactive-streams API has to be integrated in JDK9,
> the only compelling reason I see is the one given by Doug, people will try to
> use Stream for that otherwise.

This is one of several reasons, all along the lines of:
The primary mission of j.u,c is to provide efficient, well-specified,
standardized well-tested  basic concurrency support components.
If we don't introduce some pubsub-style interfaces, then we cannot
provide components that meet requirements of a growing segment
of our primary audience of infrastructure and middleware developers
(and occasionally wider audiences). For example SubmissionPublisher
is the kind of component that several people building async systems
have complained over the past few years that we do not provide.
(The situation is somewhat analogous to the introduction of

The particular choice of Flow/reactive-stream interfaces is the
best way I know to carry this out. The interoperable APIs are bland
and awkward enough that many people will build on top of them for
application-programmer-visible usages. We can/should include a
few of these, like the Flow.consume and Flow.stream methods,
but don't have any kind of world-domination plan for reactive
middleware systems (or any other middleware systems. We just
provide support to them, and love them all equally.)

While I'm at it: One set of uncertainties is whether/how to
provide Flow components based on async IO. We mostly stay
out of the IO business in j.u.c, in part because concurrent
IO usages may use any of the many java.io/nio APIs and
policies surrounding them just to configure usage.  For example,
it would be possible (and not very hard) to add a utility to
use a Socket (or AsynchronousSocketChannel) as a Publisher.
But doing so would require mechanisms/policies for pooling
ByteBuffers, dealing with socket options, and so on. One possibility
(in the spirit of methods like Flow.consume) is to offer a
few simple ones, that can also serve as a model for others.


More information about the Concurrency-interest mailing list