RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap

Remi Forax forax at univ-mlv.fr
Thu Jun 13 21:48:40 UTC 2013

On 06/13/2013 05:42 PM, Mike Duigou wrote:
> On Jun 13 2013, at 00:56 , Paul Sandoz wrote:
>> On Jun 13, 2013, at 8:42 AM, Peter Levart <peter.levart at gmail.com> wrote:
>>> On 06/13/2013 01:14 AM, Mike Duigou wrote:
>>>> On Jun 12 2013, at 15:49 , Remi Forax wrote:
>>>>> On 06/12/2013 11:23 PM, Mike Duigou wrote:
>>>>>> Hello all;
>>>>>> This patch adds optimized implementations of Map.forEach and Map.replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
>>>>>> http://cr.openjdk.java.net/~mduigou/JDK-8016446/0/webrev/
>>>>>> The implementations traverse the map more efficiently than the default iterator implementation and sometimes avoid creation of transient Map.Entry instances. The fast-fail behaviour of the default implementation is retained.
>>>>>> Mike
>>>>> Hi Mike,
>>>>> funnily I was writing HashMap.forEach/LinkedHashMap.forEach at the same time.
>>>>> (you need also to override forEach in LinkedHashMap because the one you inherits from HashMap doesn't use the linked list of entries).
>>>> I don't think we need to offer a guarantee of ordering for the forEach but using the linked list is probably more efficient.
>>> The javadoc for Map.forEach says differently:
>>> default void forEach(BiConsumer  <http://download.java.net/jdk8/docs/api/java/util/function/BiConsumer.html><? superK  <http://download.java.net/jdk8/docs/api/java/util/Map.html>,? superV  <http://download.java.net/jdk8/docs/api/java/util/Map.html>> action)
>>> Performs the given action on each entry in this map, in the order entries are returned by an entry set iterator (which may be unspecified)
> Would anyone object to removing the ", in the order entries are returned by an entry set iterator (which may be unspecified)" clause? It seems like unnecessary over-specification.
> Mike

No :)
I think it's an important property because with that property people can 
refactor from a for(:map.entrySet()) to a map.forEach() and vice-versa.


>> Right, LinkedHashMap should preserve the encounter order on traversal, bulk or otherwise.
>> Note that there is a bug logged against LinkedHashMap.spliterator. It should but currently does not report ORDERED for key/value/entry Spliterators.
>> Paul.

More information about the core-libs-dev mailing list