RFR: 8005051: optimized defaults for Iterator.forEachRemaining (original) (raw)

Paul Sandoz paul.sandoz at oracle.com
Fri Apr 26 12:50:05 UTC 2013

On Apr 26, 2013, at 2:06 PM, David Holmes <david.holmes at oracle.com> wrote:

To avoid blocking the feature, I have filed https://jbs.oracle.com/bugs/browse/JDK-8013150 to refine the behavior of remove and other ListIterator methods after forEachRemaining returns. I think the fact that the last element can be removed should be specified as unspecified, because it's more an artefact of the default implementation than something which part of the semantics. I was wondering about that too. What happens if an implementing class decides later on to override the default implementation? If the overriding implementation does not conform to the same behaviour as the default it could break compatibility. Plus one could change code from: while(it.hasNext() { doSomething(it.next()); } doSomethingAtEnd(it); to it.forEachRemaining(this::doSomething} doSomethingAtEnd(it); All implementations must obey the contract of the specification, and no clients should assume any kind of behaviour beyond what that contract says. That said I've lost the context of this particular issue - what is the problem here?

What is the state of the Iterator after a call to Iterator.forEachRemaining e.g.:

void doSometingAtEnd(Iterator it) { it.remove(); }

IMO overriding forEachRemaining implementations should place the iterator in the same state as the default method implementation. We just need to call this out more clearly in the docs.

Paul.

More information about the core-libs-dev mailing list