Flow.Publisher<Void>

[Stephane Maldini]

IMHO, face to face discussions will always beat ML arguments. Anyhow from a
Spring perspective it makes sense, this is the route Spring Data has taken  (on
top of couchbase, cassandra, mongo etc)  plus some DB drivers such as
Lettuce (Redis), R2DBC (Postgres). Beyond data, we find the same patterns
in everything Rx, Reactor or Spring (mvc, webflux, security, boot, ...), I
think Viktor K was also arguing in favor of this previously in the ML and
it seems Doug Lea was envisioning something similar when we started the RS
spec. We might only represent a small voice of the JVM community but still
an actively interested audience, and I would love to see more of
Flow.Publisher use by the JDK itself.

For the technical reasons, I find quite a few benefits in a Publisher based
API :
- direct composition via the various reactive library implementors
- deferred execution, which is the point of Publisher in general: leave the
state/payload alone until a consumer is ready
- Publisher<Void> has little implementation overhead since there is no
request/onNext dance. It still fully respects/represents the intent of the
reactive-streams specification: onSubscribe, onNext*, (onComplete|onError)?
in a typed fashion (<Void>).
- isolated, repeatable actions since everything happens on subscribe.
Implementations have the choice to defer state creation and isolate it per
subscription, no extra thread coordination required.

Eventually the JDK could consider a default toCompletionStage() on
Flow.Publisher for convenience when no reactive lib is used. Also in the
future with Project Loom, there might be some interest for an Async
Iterable as well. Both of those are easy to build from Flow.Publisher,
since the decision to start a task is properly isolated and deferred.

A few years ago a couple reactive-streams contributors were in favor of
adding a specialized Publisher contract to define empty or single
emissions, but the simplicity of 3+1 contracts was just too appealing to
add a special case Publisher. In Reactor and Rx we still value the
cardinality differentiation without relying on CompletionStage for the
reasons stated above but I don't see it as a blocker for an audience of
implementors like ADBA will have. Yes for a single emission like
Publisher<Session> we might have to do a request(1) or request(Long.MAX) if
we were to implement our own session Subscriber, but I don't see it
happening that often:
 - Direct ADBA use might be limited to driver implementors which will
either understand and test for this small requirement or just use an
existing reactive lib
 - a Subscriber that only receives zero or one value is pretty trivial to
implement
 - ADBA should aim to make it easy for implementors to expose their db
behaviors in an isolated way instead of eagerly forcing coordination with
CompletionStage based API. A low level contract like RS or ADBA should
encourage behavior first because this is a behavior contract above all.
 - nothing prevents the contract to introduce default CompletionStage API
relying on abstract/non-default Publisher based API, but I would rather see
such conversion util on Flow.Publisher directly.

I wasn't present at this meetup but I'm pretty happy the community here was
able to discuss with Douglas. I should come to those events more often :D

Cheers !


On Sat, Jul 28, 2018 at 2:29 AM, Lukas Eder <lukas.eder at gmail.com> wrote:

> As this topic has been discussed many times on this list before with no
> success, I'm very curious to learn what kinds of arguments at the SFJUG
> finally made you change your mind about the topic. I'm sure I can learn a
> trick or two in persuasive techniques :-)
>
> Am Do., 26. Juli 2018 um 17:54 Uhr schrieb Douglas Surber <
> douglas.surber at oracle.com>:
>
> > I presented ADBA at the San Francisco Java Users Group last night. It was
> > great. There were a number of folks who were strong advocates of reactive
> > streams and we talked for well over an hour after the presentation ended.
> > The kind of feedback we got last night is critical to the future success
> of
> > this project.
> >
> > This discussion resulted in a concrete proposal to make ADBA better
> > integrate with reactive streams. I’m working on the API updates in a
> branch
> > and will push that branch ASAP. At present this is strictly a idea under
> > discussion as it is a substantial change and we won’t go down this path
> > without more discussion from the wider community.
> >
> > The proposal is easy to describe though there are definitely some tricky
> > bits in the actual API design.
> >
> >  - Replace Submission everywhere with java.util.concurrent.Flow.
> Publisher
> >  - Replace ParameterizedOperation.set(String, CompletionStage, SqlType)
> > with set(String, Publisher, SqlType)
> >  - Make DataSource a Publisher<Session>
> >
> > That’s the core idea but there will be other changes. Effectively this
> > replaces all uses of CompletionStage with Publisher. Not exactly because
> it
> > also removes Submission as it is not needed.
> >
> > I have one small question. CompletionStage<Void> is ok. It is used to
> > signal that an Operation completed with no result. Is Publisher<Void>
> ok? I
> > assume that such a Publisher could only call onComplete or onError which
> is
> > just what is needed for these use cases.
> >
> >
> >
> >
>



-- 
*Stéphane*
--