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

Doug Lea dl at cs.oswego.edu
Fri Dec 14 09:56:05 PST 2012

On 12/14/12 11:57, Brian Goetz wrote:

We do not have explicit parallel versions of forEach for anything yet. Existing forEach methods are inherently sequential.

But does any spec promise this?

I still find the name "compute" very unsatisfying,

As I mentioned, I initially didn't like these names at all. Pasted here for convenience:

V computeIfAbsent(K key, Function<? super K, ? extends V> f); V computeIfPresent(K key, BiFunction<? super K, ? super V, ? extends V> f); V compute(K key, BiFunction<? super K, ? super V, ? extends V> f); V merge(K key, V value, BiFunction<? super V, ? super V, ? extends V> f);

Starting from scratch, I might call computeIfAbsent "establish". (Three years ago, when considering a MapMaker-like j.u.c class, I proposed several names along these lines but eventually gave up.)

But given computeIfAbsent, the name computeIfPresent seems forced, and then computeIfAbsentOrPresent==compute seems forced. And if you see the scheme laid out in this way, looks OK. Which is presumably why all the CHMV8 users seem to like it.

I still find the name "compute" very unsatisfying, since it carries overtones that computing is something that happens once. I think either casting it as an alternate signature of merge (so there's merge(k, v, f) and merge(k, f)) would be better than the status quo.

The main problem with "merge" for this method is that it obscures the fact that it can act as either computeIfAbsent or computeIfPresent (assuming a function that distinguishes null arg).

-Doug

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