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

Remi Forax forax at univ-mlv.fr
Fri Jun 14 07:16:45 UTC 2013

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

More information about the core-libs-dev mailing list