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

[Remi Forax]

On 06/14/2013 01:27 AM, Mike Duigou wrote:
> On Jun 13 2013, at 14:56 , Remi Forax wrote:
>
>> On 06/13/2013 04:47 PM, Paul Sandoz wrote:
>>> On Jun 13, 2013, at 4:06 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>>>>>> There is a difference between an Iterator/forEach and a spliterator/stream,
>>>>>> with a stream you know that the called lambdas will not interfere and mutate the source collection.
>>>>>>
>>>>> You do? I don't think there is any conceptual difference between the following w.r.t. interference:
>>>>>
>>>>>    ArrayList l = ...
>>>>>    l.stream().filter(...).forEach(e -> l.add(e));
>>>>>    l.spliterator().forEachRemaining(e -> l.add(e));
>>>>>
>>>>> and:
>>>>>
>>>>>    ArrayList l = ...
>>>>>    l.forEach(e -> l.add(e));
>>>>>    l.iterator().forEachRemaining(e -> l.add(e));
>>>>>
>>>>> Of course we have (or will have) strong wording saying don't implement interfering lambdas, but we still have to check for co-modification in the traversal methods of ArrayList spliterator.
>>>> Isn't it because if you remove an element from an ArrayList while iterating you can see a stale value ?
>>>> While with a HashMap, if you have only one thread, you can not see a stale entry ?
>>> Assuming just one thread do you agree that in all of the above examples the only way the list can be interfered with is by the Consumer instance e -> l.add(s) ?
>> yes, as I said to Mike, what is important IMO is that the semantics of forEach and the semantics of for(:) should be the same.
> This seems like an undue restriction unless the order of elements in the entry set is specified. Otherwise it implies a dependence upon an unspecified order. To guarantee that forEach and for(:entrySet) will use the same unspecified order seems an inappropriate. Would you tolerate:
>
>       * Performs the given action on each entry in this map until all entries
>       * have been processed or the action throws an {@code Exception}.
>       * Exceptions thrown by the action are relayed to the caller. The entries
>       * will be processed in entry set iterator order unless that order is
>       * unspecified in which case implementations may use an order which differs
>       * from the entry set iterator.
>
> I really want to avoid tying the hands of future implementators.

Noble goal :)
Exceptions can be only unchecked exceptions (Error or RuntimeException).
Otherwise the wording are Ok for me.

> The most frustrating specifications to conform to are those which were unnecessary or poor judgement.

BTW, I've a following patch for HashMap only that clean the dirt;
remove all warnings, remove all unused variables, unnecessary cast, 
unecessary generated constructors, etc.
Could you create a bug for that ?

>
> Mike
>

Rémi