SPI vs Third party dependency

[Douglas Surber]

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