Why still retain Iterator.remove()

[Paul Sandoz]

On Dec 4, 2012, at 10:01 AM, Gernot Neppert <mcnepp02 at googlemail.com> wrote:

> I have to admit that until very recently I'd thought that
> java.util.streams.Stream extends java.util.Iterable.
> While toying with one of the latest JDK8 snapshots, I realized my mistake.
> Immediately a question pops up:
> Why does java.util.Stream still return a java.util.Iterator with its
> "optional" remove() method?
> As far as I can see, Iterator.remove() is nowhere implemented in the entire
> streams package, thus it always throws UnsupportedOperationException.
> 
> If Stream isn't bound by Iterable's contract anymore, why not simply return

> a java.util.StreamIterator without remove()?
> 

For interoperability and convenience, many things consume Iterator. 

The Stream.iterator() method is an "escape hatch" to consume the stream.


> (Then, of course, java.util.Iterator could be refactored to exend
> StreamIterator)
> 
> To me, this looks like a good oppurtunity to clean things up and do away
> with one of Java's little idiosyncrasies.
> 

If we were able to wind the clock back that might be possible :-)

Thanks to default methods producers of Iterator are no longer required to implement the optional remove().

Paul.