Replace RowOperation.initialValue() and rowAggregator() by collect(Collector)

[Lukas Eder]

2017-10-26 18:56 GMT+02:00 Douglas Surber <douglas.surber at oracle.com>:

> ArrayCountOperation and OperationGroup already done. (BatchCountOperation
> has been replaced by ArrayCountOperation.)
>
>
Perfect


> Example of dependency on T:
>
>     String sql = "call generate_paycheck(?, ?)";
>     conn.<CheckDetail>outOperation(sql)
>             .set("1", emp, JdbcType.STRUCT)
>             .outParameter("2", JdbcType.STRUCT)
>             .resultProcessor(m -> m.get("2", CheckDetail.class))
>             .submit()
>             .getCompletionStage()
>             .thenAccept( (d) -> { printPaycheck(d); });
>

But why is the dependency needed throughout the call chain? outOperation()
doesn't need the witness. set() doesn't need it. And if resultProcessor
were a generic method, it would not need it either, but infer the type from
the argument Function. If we didn't have a resultProcessor (because we
don't care about the OUT parameters), we would simply have an
OutOperation<Void> or OutOperation<?> at the completion stage step.

I know that having a generic method in the middle of such a call chain
seems weird. We start out with some type <R> that would be first inferred
to some wildcard capture, and then suddenly, in the middle of the call
chain, we're switching it to something else.

Perhaps this could be dealt with using a more formal DSL API rather than
just a fluent API (e.g. like jOOQ). Each method could return a completely
new intermediate builder type. This is what I mean:
https://blog.jooq.org/2012/01/05/the-java-fluent-api-designer-crash-course/

Of course, that might be overkill for JDBC, and harder to keep backwards
compatible.

Again, I don’t like the necessity of the type witness, but I have no
> problem with the notion of saying that idiomatic ADBA places a type witness
> before every call to an Operation factory method. I have had no problem
> adopting that idiomatic usage in writing example code. I just type
> “conn.<TypeWitness>fooOperation(…” almost automatically every time. No,
> it is not ideal but I do not consider it a huge problem.
>

I do have a problem, and I am willing to take bets that the community will,
too. Generics are already hard enough to grasp for most junior developers.
Having a single JDK API that does generics very very differently from
everyone else (mostly requiring a witness) is not good.

I do think this area is worth re-designing. I'm sure there's a simple,
reasonable solution that works more like the Stream API: Without type
witnesses, profiting from the existing inference capabilities.