ConcurrentHashMap/ConcurrentMap/Map.compute

[Doug Lea]

On 12/14/12 13:32, Brian Goetz wrote:
> There's always
>
>    map.entrySet().parallel().forEach()

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

But if so, there's no way to get the par/seq distinction.
Which might be OK because ...

>
> But, let's uplevel this.

I'm not sure we want to, because we then hit some familiar
territory that might be best avoided for JDK8:

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

These make for a nice minimal set for a
null-intolerant unordered concurrently-weakly-iterable
concurrent map. (Which is by far the most commonly encountered
form for parallel bulk map ops. As in hadoop etc etc).

But generalizing these to apply to all possible maps leads to a
lot of snags. Many more than collections/streams. (As you
apparently agreed when scrapping MapStream.)

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.

This move would give people a chance to take
interface/framework issues up again someday.

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?

-Doug