ConcurrentHashMap/ConcurrentMap/Map.compute (original) (raw)

Brian Goetz brian.goetz at oracle.com
Fri Dec 14 12:01:52 PST 2012

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?

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