Map Default Methods

[Mike Duigou]

I don't think any of these are blockers for the current review. We can change our answers later in future commits.

Mike

On Apr 11 2013, at 09:49 , Brian Goetz wrote:

> If getOrDefault is going to hold up the train here, we should consider peeling it off and handle separately, since it was only added as a "while we're here" and not currently used by any of the code that this putback is blocking.
> 
> On 4/11/2013 12:32 PM, Mike Duigou wrote:
>> Hi Doug;
>> 
>> I wanted to call your attention to three points in the the current ongoing review of the proposed Map default methods.
>> 
>> - I've added an additional default getOrDefault() to ConcurrentMap which preserves the atomic behaviour of ConcurrentMap at the cost of not supporting null values in maps.
>> 
>> - I've changed the method documentation warning regarding synchronization, atomicity, concurrency. Please ensure that it still matches your intent:
>> 
>>      * <p>The default implementation makes no guarantees about synchronization
>>      * or atomicity properties of this method. Any class which wishes to provide
>>      * specific synchronization, atomicity or concurrency behaviour should
>>      * override this method.
>> 
>> - The retry behaviour of the compute(), computeIfPresent() and merge() defaults makes sense for concurrent maps but possibly not for non-concurrent maps. For non-concurrent maps the retry behaviour will mask concurrent usage errors. How do you feel about moving these defaults (along with computeIfAbsent()) to ConcurrentMap and providing implementations that generate ConcurrentModificationException for the Map defaults?
>> 
>> Thanks,
>> 
>> Mike
>>