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

Joe Bowbeer joe.bowbeer at gmail.com
Fri Dec 14 10:21:29 PST 2012

I think that most if the initial users of the compute methods will already be familiar with the 'compute' names. I am, as is Doug. On Dec 14, 2012 10:02 AM, "Brian Goetz" <brian.goetz at oracle.com> 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? 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20121214/b70eae5c/attachment.html

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