Additional Collectors

[Brian Goetz]

This should be handled by the two overloadings of toMap.  The general one:

   toMap(Function<T,U>, Supplier<M>, BinaryOperator<U>)

takes a merge function which resolves duplicates.

The default form:

   toMap(Function<T,U>)

implicitly uses a merge function which throws.  The doc says:

If the input elements contains duplicates
(according to {@link Object#equals(Object)}), an {@code 
IllegalStateException} is thrown when the
collection operation is performed.

for the basic form and documents the use of the merge function for the 
more general form.

Is that not adequate?

On 4/3/2013 2:21 PM, Ali Ebrahimi wrote:
> Hi brian,
> I have concerns about toMap method and this may result in unexpected and
> unpredictable results in user program, and this method only have mean
> for unique collections (Set) and streams (resulted for Stream.distinct).
> Consider this example:
>
> class Entity{
>       int id;   //key field
>       String name;
>   // override equals and hashcode
> ....
> }
>
> Entity foo = new Entity(1, "Foo");
> Entity bar = new Entity(1, "Bar");
> List<Entity> entities = list(new Entity(0, "Some"),foo,..., bar,...)
>
> Map<Entity,String> entitymap=entities.stream().collect(ToMap(e -> e.name
> <http://e.name>));
>
> what is result of entitymap.get(foo)? "Foo" or "Bar"
>
> Map<Entity,String> entitymap2=entities.parallelStream().collect(ToMap(e
> -> e.name <http://e.name>));
>
> what is result of entitymap2.get(foo)? "Foo" or "Bar"
>
> Suggestion1: get rid of ToMap
> Suggestion 2: May be we need consider adding subclass UniqueStream with
> additional method toMap and change return type of  Stream.distinct and
> Set.stream to UniqueStream.
>
> What do you think?
>
> Ali Ebrahimi
>
>
>
>
>
> On Wed, Apr 3, 2013 at 9:57 PM, Brian Goetz <brian.goetz at oracle.com
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     There's been some feedback on lambda-dev and from the recent Lambda
>     Hack Day on Collectors.  There were two big categories:
>
>     1.  Need more / better docs.
>
>     2.  We want some more collectors.
>
>     The first is obvious and we've been working on those.  Here are some
>     suggestions for simple additions to the Collector set.
>
>       - count() (and possibly sum, min, max)
>
>     These are straighforward analogues of the specialized stream
>     methods; they serve as a "gentle on ramp"  to understanding reduction.
>
>     People also expressed concern that the "toMap()" (nee mappedTo,
>     joiningWith) is not flexible enough.  As a reminder, what toMap does
>     is take a Stream<T> and a function T->U and produces a Map<T,U>.
>       Some people call this "backwards"; they would rather have
>     something that takes a Stream<T> and function T->K and produces a
>     Map<K,T>.  And others would rather have something that takes two
>     functions T->K and T->U and produces a Map<K,U>.
>
>     All of these are useful enough.  The question is how to fit them
>     into the API.  I think the name "toMap" is a bit of a challenge,
>     since there are several "modes" and not all of them can be easily
>     handled by overloads.  Maybe:
>
>        toMap(T->U) // first version
>        toMap(T->K, T->U) // third version
>
>     and leave the second version out, since the third version can easily
>     simulate the second?
>
>