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

Lukas Eder lukas.eder at
Wed Oct 25 15:40:55 UTC 2017

2017-10-25 18:29 GMT+03:00 Douglas Surber <douglas.surber at>:

> Lukas,
> I like this suggestion. I will definitely look into it.
> I agree about the type witnesses. I’m hoping that a future improvement in
> type inferencing will eliminate the need.

Me too, but I'm not very hopeful. There had been a few ideas around JEP
101, which have been rejected due to the complexity they would have

Essentially, type inference would need to work in "both ways", traversing a
call chain from left to right *and* right to left, similar to a constraint
solving system. That's risky in terms of compilation speed and

So, ideally, the new API would not rely on any such future feature, if it
can be re-designed.

The collect method does not eliminate the need for the type witness
> completely. The type inferencer cannot determine the type of the
> RowOperation from it. There are some special cases where replacing
> initialValue/rowAggregator with collect does eliminate the need for the
> type witness, but there are many other cases where it doesn’t help.
> Unfortunately the limitation of the type inferencer necessitate the type
> witness in some cases. My approach has been to always write the type
> witness; it needs to idiomatic for this kind of heavily typed fluent API.

I'm quite optimistic that it should be feasible. I think this isn't a
language problem, but a problem with the current API suggestion. jOOQ users
(another heavily typed fluent API if you want) hardly ever requires its
users to use type witnesses. Neither does the Stream API (except for edge

In my suggestion, I assumed that OperationGroup.rowOperation could return a
RowOperation<?>, and only calling the RowOperation.collect() method would
make the type parameter more concrete, thus collect() would have to be a
generic method. All the other methods on RowOperation currently do not rely
on its type parameter.


More information about the jdbc-spec-discuss mailing list