Flow.Publisher<Void>

[Julien Viet]

Hi,

my personal opinion is that CompletionStage / Publisher based API are easier to read and understand without ambiguity as I can map CompletionStage to a single value and Publisher to a stream.

my 2c.

Julien

> On 27 Jul 2018, at 03:13, James Roper <james at lightbend.com> wrote:
> 
> Hi Douglas,
> 
> I'm not for this change.
> 
> One problem with it is that there are quite a number of other standard
> APIs, both in the JDK (eg the new HTTP client) as well as in Java EE (eg
> JAX-RS, CDI, and a number of the new MicroProfile APIs) plus a myriad of
> open source libraries that have already embraced CompletionStage as the
> abstraction to use to asynchronously provide exactly one value, or to
> signal completion (a la CompletionStage<Void>). Some of these APIs are
> looking to or have adopted Reactive Streams/juc.Flow, but only for
> streaming, not for asynchronous single values. When all libraries use the
> same abstraction for the same use case, then they become easy to use and
> integrate with each other. When they use different abstractions, then you
> need bridges to integrate them with each other, which has the effect of
> making it harder for end users to use them, the code they write becomes
> harder to read due to all the bridging wrappers, etc.
> 
> So, if let's say I need to load something from the database, then make an
> HTTP call, if both the database adapter and that HTTP client use
> CompletionStage, this is easy as:
> 
> CompletionStage<Response> response = database.executeQuery()
>  .thenCompose(result ->
> httpClient.makeRequest(convertResultToRequest(result)));
> 
> I can add other asynchronous operations from other libraries to my hearts
> content and the code still stays easy to read because everything is using
> the same abstraction. However, if ADBA used reactive streams for this, then
> you would need to convert the publisher to a CompletionStage. It would be
> the only API in the Java standards ecosystem that uses streams in this way,
> which would make it stand out like a sore thumb, every other Java standard
> that supported asynchronous IO would integrate nicely together using
> CompletionStage, but when it came to using ADBA, everyone would have to use
> a bridging wrapper.
> 
> Reactive streams is great for streams - I am a massive proponent of it
> being used for the right use case. But it includes a lot of mechanics (and
> performance overhead) to meet the needs that streams have, including
> handshaking to establish a subscription, and then tokens for backpressure.
> A single value made asynchronously available in the future is not a stream,
> it doesn't require back pressure because there's only one value, not
> potentially infinite, it doesn't require the overhead of a subscription
> because the semantics are much simpler. These things get in the way both
> performance wise and they also make it more complex to use and implement.
> Of course, you *can* use a stream to provide a single value, I'm not
> disputing that. You can also use a Collection to represent a single value
> that may or may not be present - but that's not what it's designed for,
> java.util.Optional is designed and optimised for that, and makes it much
> clearer to uses when they see it what is actually being provided. The same
> goes with CompletionStage vs Publisher.
> 
> Regards,
> 
> James
> 
> On Fri, 27 Jul 2018 at 02:04, Douglas Surber <douglas.surber at oracle.com>
> wrote:
> 
>> 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.
>> 
>> 
>> 
>> 
> 
> -- 
> *James Roper*
> *Senior Developer, Office of the CTO*
> 
> Lightbend <https://www.lightbend.com/> – Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>