Rationale behind having type variables <A> for Collector's accumulator types in public APIs

Lukas Eder lukas.eder at gmail.com
Mon May 7 09:00:25 UTC 2018


Hello,

I'm currently designing API that I'd like to keep somewhat consistent with
the Stream API and I've stumbled upon Stream.collect(), whose signature is:

  <R, A> R collect(Collector<? super T, A, R> collector);

For most common usages, I would imagine that this signature would have
worked just as well:

  <R> R collect(Collector<? super T, ?, R> collector);

In fact, it seems to be a nicer signature for the caller in edge cases
where a type witness for <R> is needed, because in the current API, a
witness for <A> has to be supplied as well, which seems unnecessary, if not
for even rare edge cases.

I understand that the ReferencePipeline's implementation is happy about
being able to name the accumulator type rather than capturing it in a
private auxiliary method or resorting to raw types, but I doubt that this
is really an implementation detail having leaked into the API, given that
much of the Collectors API also exposes the accumulator type as a type
variable.

What's the reason for <A> being in the public API?

Thanks,
Lukas


More information about the core-libs-dev mailing list