ConcurrentHashMap/ConcurrentMap/Map.compute

[Brian Goetz]

>>    map.entrySet().parallel().forEach()
>
> I'm guessing you also declared the Map version in because
> it can take BiBlocks, not Block<Map.Entry>?

The main two reasons we flirted with MapStream were the above (want to 
deal in BiXxx instead of Xxx(Map.Entry)) and also that we wanted to have 
some finer-grained operations (like, reduce values associated with a 
given key.)  But, reduceBy (and its spiritual descendents) eliminated 
the latter.

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.

>>   - What *other* operations do you want to expose in parallel other
>> than forEach?
>
> Well, there are the ones exported in CHM. See pre-JDK8 snapshot still at:
> http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/ConcurrentHashMap.html

Are you willing to have .foo and .parallelFoo versions?

> 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.

> But a near-term victim is that if you want to just add a
> common plain forEach(BiBlock), we have no good story about
> how to spec it to allow both seq and par forms, or a place
> to put it that would implicitly allow both forms.
>
> Maybe just scrap it?

What about the stream form above plus a block adapter?