RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap (original) (raw)
Mike Duigou mike.duigou at oracle.com
Thu Jun 13 23:27:24 UTC 2013
- Previous message: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
- Next message: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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. The most frustrating specifications to conform to are those which were unnecessary or poor judgement.
Mike
- Previous message: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
- Next message: RFR : 8016446 : (m) Add override forEach/replaceAll to HashMap, Hashtable, IdentityHashMap, WeakHashMap, TreeMap
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]