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

Joe Bowbeer joe.bowbeer at gmail.com
Wed Dec 5 15:06:15 PST 2012

I slightly prefer computeIfPresent.

replaceIfPresent sounds redundant and its name does not imply computation. I'd like all the compute* methods to be listed together.

Bikeshed: The name "replaceIfPresent" seems nicer than "computeIfPresent" and fits in with existing replace naming.

OK; none of the names of it are beautiful, but either the analog-of-computeIfAbsent of of replace fine. (I at first had this as just "replace", but it can clash with the other form of replace in weird cases where you have a map of keys to functions.)

On Wed, Dec 5, 2012 at 1:50 PM, Doug Lea <dl at cs.oswego.edu> wrote:

On 12/05/12 16:31, Brian Goetz wrote:

These look great to me! This default method thing was a pretty good idea! :)

Nit: uses Scala fat arrow instead of Java thin arrow in examples. (Oops! A byproduct of talking about Scala in a course here yesterday :-)

Bikeshed: The name "replaceIfPresent" seems nicer than "computeIfPresent" and fits in with existing replace naming. OK; none of the names of it are beautiful, but either the analog-of-computeIfAbsent of of replace fine. (I at first had this as just "replace", but it can clash with the other form of replace in weird cases where you have a map of keys to functions.)

For the value-oriented CHM methods (putIfAbsent, remove, replace), I think it is reasonable to move these up to Map with the obvious defaults, with no promises about atomicity, and adjust the ConcurrentMap spec to add a comment about "unlike the Map versions, these are atomic." The null rules get more ad-hoc for these, but can still be reasonably consistent with the lambda versions; NPE on any key being null. For replace(K,V,null), we can treat that as remove-if-present and replace(K,null) can be unconditional remove. putIfAbsent(k, null) should be a no-op. remove(key, null) becomes "remove if get() returns null", I guess. I agree. Changing replace(K,null) would be a CHM spec change (now throws NPE) but an innocuous one since it makes an illegal case legal, and is good for sake of consistency. I'll flesh these out and resend sometime soon. ObAndIWantAPony: I would also love to have Map.merge(otherMap, mergeLambda) whose default uses your merge below, but for which you could define a better override in Map implementations that offer a better than element-wise merge. Well, you have the pony, but it's not in your favorite color: It's easy via the CHM bulk ops. (And was once a listed example but somehow I clobbered it. I'll put it back in.) It's not in any interface now that we don't have MapStreams. And probably not a great idea to add at Map level in case the need for something like MapStream arises again. -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/attachments/20121205/6ef1fa34/attachment.html

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