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

Doug Lea dl at cs.oswego.edu
Fri Dec 7 04:58:39 PST 2012

On 12/07/12 02:18, David Holmes wrote:

Right. The idea is that ALL of these would have the same disclaimer as the new lambda-friendly ones I listed:

* *

The default implementation makes no guarantees about

* synchronization or atomicity properties of this method. Any * class overriding this method must specify its concurrency * properties. * Which means that ConcurrentMap has to re-abstract all the new methods as their default implementations are invalid for maps that people expect atomic operations from.

Yes/no. There is some risk in doing this in the way I posted for both the four existing ConcurrentMap and four added functional-form methods: A concrete concurrent class will no longer be forced by a compiler to override to provide atomicity. And there is of course no way we can do it for them. But users will naturally expect otherwise. This is why I've been fleshing these all out, so people could help decide if this is the best move. I'm still thinking barely-yes, but am a little nervous about it.

-Doug

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