toMap options

Brian Goetz brian.goetz at oracle.com
Tue Apr 9 14:29:21 PDT 2013


Currently we have:

     Collector<T, Map<T,U>>
     toMap(Function<? super T, ? extends U> mapper)

and

     <T, U, M extends Map<T, U>>
     Collector<T, M>
     toMap(Function<? super T, ? extends U> mapper,
           Supplier<M> mapSupplier,
           BinaryOperator<U> mergeFunction)

(plus concurrent versions of both of these.)  The former is just sugar for:

   toMap(mapper, HashMap::new, throwingMerger())

(We have predefined merge functions for throw-on-duplicates, first-wins, 
and last-wins, called throwingMerger, firstWinsMerger, and lastWinsMerger.)

As has been noted, we do not yet serve the use case of creating a map 
where the stream elements are the values of the map instead of the keys 
of the map.  Options for addressing this are:

1.  Leave toMap as is, add toIndexedMap (or toKeyedMap) variants.

2.  Leave toMap as is, add a two-function version of toMap:

     <T,K,U>
     Collector<T, Map<K,U>>
     toMap(Function<T, K> keyMapper,
           Function<T, U> valueMapper)

in which case the regular toMap becomes sugar for

     toMap(Function.identity(), mapper)

3.  Get rid of the current form of toMap, and just have the two-function 
form as in (2).

4.  Break free of the toMap naming (recall that until recently this was 
called mappedTo, and prior to that, joiningWith), and have two versions: 
mappedTo and mappedFrom.  This is explicit, but also doesn't address the 
use case where both key and value are functions of the stream elements.

Others?



More information about the lambda-libs-spec-observers mailing list