a patch for new default methods in Map + more

Peter Levart peter.levart at gmail.com
Fri Jan 4 09:11:34 PST 2013


Hi,

I propose a patch for some new default methods in j.u.Map and some more:

http://dl.dropbox.com/u/101777488/jdk8-lambda/Map/webrev.02/index.html

The patch consists of 3 parts. Each can be taken individually or 
together (or not at all).

*1st part* is a patch to methods Map.compute and Map.merge.

The Map.compute changes fix a NPE or infinite loop when executing the 
following code:

         Map<Integer, String> map = new HashMap<>();
         map.compute(1, (k, v) -> "x");

...loops infinitely and:

         Map<Integer, String> map = new ConcurrentHashMap<>();
         map.compute(1, (k, v) -> "x");

...throws NPE.

In conversation with Doug we came to conclusion that this is the best we 
can do (so far). The semantics of compute is now such that if there is 
already a mapping in the Map {key->null} and a compute is called for the 
key, the mapping will not be touched although the method will return the 
value produced by the function. This behaviour is consistent with 
computeIfAbsent and merge.

The Map.merge changes are just optimization (the returned value from the 
putIfAbsent is used in new iteration of loop saving another get). 
Otherwise the semantics stays the same.

*2nd part* is a little javadoc change in ConcurrentMap.remove(k, v) and 
ConcurrentMap.replace(k, oldV, newV) as well as those two methods in 
j.u.Map. The corresponding default methods in j.u.Map are changed 
accordingly. This change eliminates a NPE when there is already a 
mapping present in Map {key->null} and those methods are called with the 
key.

*3rd part* is just a preview. All 8 new default methods of j.u.Map are 
re-implemented in j.u.HashMap so that they are more optimal. The 
semantics (also the behaviour with null keys/values as arguments and as 
entries already in the map) should be exactly the same as that of 
default methods in j.u.Map. Javadocs and tests are missing, but I'm 
going to add them if this is something that might be considered to be 
included.


Regards, Peter



More information about the lambda-dev mailing list