ConcurrentHashMap/ConcurrentMap/Map.compute

[Doug Lea]

On 12/14/12 15:01, Brian Goetz wrote:

> Some combinators that take a Bi{Block,Predicate,Function} and produce a
> {B,P,F}(Map.Entry) could help with the former.  For example:
>
>    map.entrySet().stream()
>       .forEach(forEntry((k,v) -> { ... });
>
> This would trade O(n) "e.getKey()/getValue()" goo for O(1) wrapping goo.

Although considering that many maps generate per-iteration Entry objects,
this amounts to double-wrapping. I suppose the convenience outweighs the
overhead for the audience most tempted to use it though.

>
>> I had been thinking that the best move for JDK8 is for CHM itself
>> to either only support parallel forms (as it does at the moment)
>> or to offer both seq and par forms of these
>> (foreach, mapped-foreach, search, reduce, mapped-reduce, and
>> primitive-mapped-reduce, crossed by the four flavors:
>> keys, values, entries, and Bi-forms), without trying to
>> create new interfaces.
>
> Messy (for you) but probably the most option-preserving choice.
>

Any preferences about which form? I omitted seq forms in
current version so as to release the par ones without
stalling over whether they'd be segregated under something
sharing common interface. But now that this option seems out
(no MapStreams) I'm left with the usual choices of how
to name and/or parameterize them. Probably:
    forEach{Key,Value,Entry,<mapping>}Sequentially /  forEach{...}InParallel
    reduce{...}Sequentially / reduce{...}InParallel
    search{...}Sequentially / search{...}InParallel
Luckily there are only three method name stems,
all short enough that this is tolerable. Plus, the explicit
"Sequentially"/"InParallel" leave avoid clashes with several
pluasible future options.

All of these would be in the CHM class itself.
The CHM key, value, entry view classes as well as the
CHM.newKeySet set projection will instead implement stream API
(which I hope to do next.)

OK?

-Doug