Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

2016-11-23 Thread Paul Sandoz
Stuart and I refined the text to mention a concurrent modification policy (e.g. fail-fast or weakly consistent) of any overriding class. Paul. diff -r c7b932897909 src/java.base/share/classes/java/lang/Iterable.java --- a/src/java.base/share/classes/java/lang/Iterable.java Wed Nov 23 10:

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

2016-11-21 Thread Martin Buchholz
On Mon, Nov 21, 2016 at 2:29 PM, Paul Sandoz wrote: > > A linked list based implementation could report hasNext() == false when > currentNode.next == null, but that might change before the next call to > hasNext(). AFAIK, all of our concrete implementations don't have this > property - the itera

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

2016-11-21 Thread Paul Sandoz
> On 21 Nov 2016, at 13:21, Martin Buchholz wrote: > > > > On Mon, Nov 21, 2016 at 1:01 PM, Paul Sandoz > wrote: > > > There's the question of what to promise after a call to forEachRemaining > > (whether or not an action threw). Perhaps a blanket > > """Subs

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

2016-11-21 Thread Martin Buchholz
On Mon, Nov 21, 2016 at 1:01 PM, Paul Sandoz wrote: > > > There's the question of what to promise after a call to forEachRemaining > (whether or not an action threw). Perhaps a blanket > > """Subsequent behavior of an iterator is unspecified after a call to > this method.""" > > > > I think that

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

2016-11-21 Thread Paul Sandoz
> On 21 Nov 2016, at 12:32, Martin Buchholz wrote: > > Thanks. Seems like progress. > > The spec below seems like it could be improved, but not sure how... > > + * > + * The behavior of an iterator is unspecified if the action performs the > + * following side-effects: > + *

Re: RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

2016-11-21 Thread Martin Buchholz
Thanks. Seems like progress. The spec below seems like it could be improved, but not sure how... + * + * The behavior of an iterator is unspecified if the action performs the + * following side-effects: + * + * modifies the underlying collection; or + * calls the {@link

RFR 8168745 Iterator.forEachRemaining vs. Iterator.remove

2016-11-21 Thread Paul Sandoz
Hi, Please review these specification clarifications to the methods Iterator.forEachRemaining and Iterator.remove. Implementations of Iterator.forEachRemaining should have some wiggle room to optimize traversal. (In hindsight we could have done a better job locking such behaviour down in Java