ConcurrentHashMap/ConcurrentMap/Map.compute

[Brian Goetz]

>> We do not have explicit parallel versions of forEach for anything yet.
>> Existing
>> forEach methods are inherently sequential.
>
> But does any spec promise this?

Our mantra has been "no transparent parallelism."  So, I think it should 
promise this.  If you want parallel forEach you can do:

   coll.parallel().forEach()

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

What about recompute for compute, and recomputeIfPresent for 
computeIfPresent?  (The former has a slight weirdness about the first 
time, since you can't recompute something that isn't yet computed, but 
that weirdness seems much less than the unapproachability of compute. 
And as far as I can tell, no one has considered these names yet.