Java: why can't iterate over an iterator?

Question

I read http://stackoverflow.com/questions/839178/why-is-javas-iterator-not-an-iterable and http://stackoverflow.com/questions/27240/why-arent-enumerations-iterable, but I still don't understand why this:

void foo(Iterator<X> it) {
  for (X x : it) {
    bar(x);
    baz(x);
  }
}

was not made possible. In other words, unless I'm missing something, the above could have been nice and valid syntactic sugar for:

void foo(Iterator<X> it) {
  for (X x; it.hasNext();) {
    x = it.next();
    bar(x);
    baz(x);
  }
}

Answer 1

Most likely the reason for this is because iterators are not reusable; you need to get a fresh Iterator from the Iterable collection each time you want to iterate over the elements. However, as a quick fix:

private static <T> Iterable<T> iterable(final Iterator<T> it){
     return new Iterable<T>(){ public Iterator<T> iterator(){ return it; } };
}

//....
{
     // ...
     // Now we can use:
     for ( X x : iterable(it) ){
        // do something with x
     }
     // ...
}
//....

That said, the best thing to do is simply pass around the Iterable<T> interface instead of Iterator<T>.

Answer 2

The for(Type t : iterable) syntax is only valid for classes that implement Iterable<Type>.

An iterator does not implement iterable.

You can iterate over things like Collection<T>, List<T>, or Set<T> because they implement Iterable.

The following code is equivalent:

for (Type t: list) {
    // do something with t
}

and

Iterator<Type> iter = list.iterator();
while (iter.hasNext) {
    t = iter.next();
    // do something with t
}

The reason this was not made possible, is because the for-each syntax was added to the language to abstract out the Iterator. Making the for-each loop work with iterators would not accomplish what the for-each loop was created for.

Answer 3

Iterators are not meant be reused (i.e.: used in more than iteration loop). In particular, Iterator.hasNext() guarantees that you can safely call Iterator.next() and indeed get the next value from the underlying collection.

When the same iterator is used in two concurrently running iterations (let's assume a multi-threading scenario) this promise can no longer be kept:

while(iter.hasNext() {
   // Now a context switch happens, another thread is performing
   //    iter.hasNext(); x = iter.next();

  String s = iter.next();  
          // A runtime exception is thrown because the iterator was 
          // exhausted by the other thread
}

Such scenarios completely break the protocol offered by Iterator. Actually they can occur even in a single threaded program: an iteration loops calls another method which uses the same iterator to perform its own iteration. When this method returns, the caller is issuing an Iterator.next() call which, again, fails.

Answer 4

Because the for-each is designed to read as something like:

for each element of [some collection of elements]

An Iterator is not [some collection of elements]. An array and an Iterable is.

Answer 5

but I still don't understand why this [...] was not made possible.

I can see several reasons:

1. Iterators are not reusable, so a for/each would consume the iterator - not incorrect behavior, perhaps, but unintuitive to those who don't know how the for/each is desugared.
2. Iterators don't appear "naked" in code all that often so it would be complicating the JLS with little gain (the for/each construct is bad enough as it is, working on both Iterables and arrays).
3. There's an easy workaround. It may seem a little wasteful to allocate a new object just for this, but allocation is cheap as it is and escape analysis would rid you even of that small cost in most cases. (Why they didn't include this workaround in an Iterables utility class, analogous to Collections and Arrays, is beyond me, though.)
4. (Probably not true - see the comments.) I seem to recall that the JLS can only reference things in java.lang^{[citation needed]}, so they'd have to create an Iterator interface in java.lang which java.util.Iterator extends without adding anything to. Now we have two functionally equivalent iterator interfaces. 50% of the new code using naked iterators will choose the java.lang version, the rest use the one in java.util. Chaos ensues, compatibility problems abound, etc.

I think points 1-3 are very much in line with how the Java language design philosophy seems to go: Don't surprise newcomers, don't complicate the spec if it doesn't have a clear gain that overshadows the costs, and don't do with a language feature what can be done with a library.

The same arguments would explain why java.util.Enumeration isn't Iterable, too.