SPI vs Third party dependency

[Dávid Karnok]

I was hoping the inclusion of the Flow API in Java SE would open the gates
for Java SE internal implementations such as a reactive JDBC API. However,
if this type of requirements, namely demonstrating only by using Java SE
tools, is present throughout any other upcoming features, that defeats the
purpose of integrating the Flow API into the JDK in the first place in my
opinion.

Writing a fluent Flow-based API is non-trivial and there are often certain
"enterprisey" features expected along the way. For example, both RxJava and
Reactor 3, have interceptors in the fluent API (assembly hooks they are
called) and offer abstractions over ExecutorServices (aka Schedulers). I
can't really imagine such hooks to be present or added to a Java SE
implementation over the Flow API.

Which brings us to the success of the industry collaboration-based
Reactive-Streams specification, requiring a library import and Java 6 as
the common ground, vendors of all sorts of dataflows and consumers can
interoperate. This practically includes database and datastore driver
writers who have built drivers exposing data as Reactive-Streams flows.
Since I'd consider the Reactive-Streams as the ultimate interoperation, the
lack of uniform way of querying a datastore doesn't hit me as much of a
problem: I get the results in a neat flow and I don't usually switch
datastore vendors that often so that the issuing the queries in a
vendor-specific way would affect me.

Consequently, if the need for an uniform query-issuing API is really
present, it could be explored and developed outside Java SE in a similar
industry collaboration as Reactive-Streams where showing examples which use
third party reactive libraries over the standalone set of SPIs is actually
a welcoming action.


2017-10-17 20:29 GMT+02:00 Douglas Surber <douglas.surber at oracle.com>:

> It is not the lack of implementations of Flow.X that is the problem. It is
> the lack of a support library that manipulates streams.
>
> If you look at the example code in the sketch David Karnok referenced in
> the Example of a Flow-based JDBC API thread you will see that the code
> makes extensive use of a reactive stream library. Writing the same example
> using the same sketch API but without a reactive stream library is
> impractical. There is (currently) no reactive stream library in Java SE so
> it would be impractical to use the sketch API in Java SE. Doing so would
> require some non standard reactive stream library. This fails to meet one
> of the goals of this project which is integration with Java SE, not
> integration with Java SE plus some random other library.
>
> Douglas
>
> > On Oct 17, 2017, at 12:29 AM, Jens Schauder <jschauder at pivotal.io>
> wrote:
> >
> > Sorry if I'm a little dense but there is something I don't really
> > understand.
> >
> > The existing JDBC, as well as the upcoming new version, is what I
> consider
> > an SPI: a set of interfaces plus rules how they should behave, which
> won't
> > get implemented in the JDK itself. Instead, other parties (in this case
> > probably database vendors) will provide implementations.
> >
> > In my eyes, the Flow API as well is such an SPI. It is intended to get
> > implemented by third parties.
> >
> > Yet you don't want to depend on it although it seems to fit the
> > requirements quite well, especially "Maximum throughput with low and
> stable
> > latency"
> >
> > So my question is: what is the fundamental difference between the Flow
> API
> > and the new async JDBC that makes it ok for one to depend on third-party
> > implementations and the other not?
> >
> > Also, if this difference is relevant beyond the scope of JDBC the
> question
> > arises how/if the Flow API is supposed to be used at all in the JDK?
> > Although that question might be better suited for a different mailing
> list?
> >
> > Just to make sure: I'm not trying to change anybody's mind. I'm just
> trying
> > to understand the underlying principles for those decisions.
> >
> > Regards,
> > Jens Schauder
>
>


-- 
Best regards,
David Karnok