So, this proposal is essentially trying to add something small to JDK 9 in advance of the long wait for value types and a full solution to the problem space. A stream of Map.Entry is painful today, and my idea or Remi's would definitely assist without pushing the API too far (I'm not such a fan of Peter's suggestion).
As it happens, we're also looking at a dedicated MapStream now: https://github.com/OpenGamma/Strata/commit/ee42c4dac90a1f08b43af6eec799d7c5e876ab4a#diff-b1758880cf04177f31c86fe8e1d5b012R36 Stephen On 15 January 2016 at 17:27, Paul Sandoz <paul.san...@oracle.com> wrote: > Hi, > > We have had multiple attempts at a BiStream for references. > > Mike had quite a good one. I thought my last attempt was rather good too > :-) it avoided boxing on critical paths, while avoiding much bifurcation of > the Spliterator API, and supported some nice use-cases. However, it would > likely stick out like a sore thumb when Value types and then Tuples arrive > (when? “when they are ready!”), and then we can do much better. > > Some small tweaks to Map.Entry might be handy, but i think beyond that and > it’s likely to start pulling on a bigger set of use-cases. > > Paul. > > > > On 15 Jan 2016, at 16:51, Tagir F. Valeev <amae...@gmail.com> wrote: > > > > Hello! > > > > SC> Finally, the Collectors class could do with a new method > entriesToMap() > > SC> that collects a stream of Map.Entry back into a Map. > > > > I was thinking about adding such collector into my library and checked > > StackOverflow to understand the useful scenarios. Seems that having > > entriesToMap() collector without arguments (even along with proposed > > mapValues()/mapKeys()) only would be too limited and solve only some > > subset of interesting problems. > > > > First, you would need to add versions with > > a) custom merging policy > > b) custom Map factory (probably could be omitted as toMap() does not > > have such overload) > > c) both > > Answers which need this: > > http://stackoverflow.com/a/22132422/ > > http://stackoverflow.com/a/33724926/ > > http://stackoverflow.com/a/30084289/ > > And many more > > > > Second, to be consistent with the current API you may need to add > > entriesToConcurrentMap() > > > > Third, sometimes you need to know both key and value to produce the > > new key. In this case proposed mapValues()/mapKeys() will not work: > > http://stackoverflow.com/a/34766036/ > > > > Fourth, very often entries from the stream should be grouped instead, > > so probably something like groupingEntries() should also be added > > (along with Map factory argument, downstream collector argument and > > concurrent version!) The most common scenario is the following: > > > > groupingBy(Entry::getKey, > > mapping(Entry::getValue, toList())) > > http://stackoverflow.com/a/25246138/ > > http://stackoverflow.com/a/31488612/ > > http://stackoverflow.com/a/30877403/ > > And many more > > > > To my opinion, creating such dedicated collector is even more > > important than toMap() as people understand toMap(Entry::getKey, > > Entry::getValue) much better than cascaded combination of groupingBy, > > mapping and toList. See Stuart Marks explaining: > > http://stackoverflow.com/a/28599035/ > > > > Sometimes it works without additional mapping: > > groupingBy(Map.Entry::getKey, summingLong(Map.Entry::getValue)) > > http://stackoverflow.com/a/34325686/ > > http://stackoverflow.com/a/31751786/ > > > > Also sometimes you need to swap key and value like here: > > groupingBy(e->e.getValue().get(0), > > mapping(Map.Entry::getKey, toList())) > > http://stackoverflow.com/a/30652372/ > > http://stackoverflow.com/a/33900949/ > > So probably Entry<V, K> swap() method would also be useful! > > > > In general it's not very evident where to draw the line between API > > simplicity and covered use cases. Hopefully my examples will help to > > take good decision. > > > > By the way in my library MapStream is called as EntryStream. Like > > IntStream is stream of ints, the EntryStream is stream of entries. > > MapStream would be the stream of maps which is not true. Also in > > context of the Stream API map often means transformation which would > > add the confusion. > > > > With best regards, > > Tagir Valeev. > > > >
