Rationale behind having type variables for Collector's accumulator types in public APIs (original) (raw)

Paul Sandoz paul.sandoz at oracle.com
Wed May 9 00:30:22 UTC 2018

Hi Lukas,

See this thread:

http://mail.openjdk.java.net/pipermail/lambda-dev/2013-June/010115.html <http://mail.openjdk.java.net/pipermail/lambda-dev/2013-June/010115.html>

Paul.

On May 7, 2018, at 2:00 AM, Lukas Eder <lukas.eder at gmail.com> wrote:

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 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 is needed, because in the current API, a witness for 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 being in the public API? Thanks, Lukas

More information about the core-libs-dev mailing list