what is the concept behind java iterator?

Question

I am doing a research on java iterator interface and cannot understand why it is designed like that.

Why java iterator use hasNext and next instead merge them into one method?

this a typical usage of java iterator

Iterator iter = //iterator from a list
while(iter.hasNext()){
    Object obj = iter.next();
    // do something to obj
}

why not

Iterator iter = //iterator from a list
Object obj = null;
try {
    while(true){
        obj = iter.next();
        // do something to obj
    }
} catch (NoSuchElementException e) {}

It is clear this approach looks ugly but what happen if next return null for when reach to end instead throw an exception? than code can be simplify to

Iterator iter = //iterator from a list
Object obj = null;
while((obj = iter.next()) != null){
    // do something to obj
}

this is how NSEnumerator in Objective-C works

NSEnumerator *enumerator = // from an array
while (id obj = [enumerator nextObject]) {
    // do something to obj
}

---

This increase the overhead of implement custom iterator.

This also make java iterator not thread-safe. For example an ArrayList have one element in it. Two threads both ask for a same iterator for that list hasNext at same time. Than both threads will see true and they will invoke next on that iterator. Because there is only one element and iterator has been asked twice which definitely will lead to an exception or error state.

I know there are thread-safe iterator but I am not sure hot it implement but I think lots blocking are happening which make it inefficient.

I think problem is that check and update are not happen atomically and I cannot understand why java designed iterator interface like that.

---

Update

I see that null can be a value so my approach is invalid. But is any possible workaround to the problems I mentioned above?

Answer 1

Your proposition would make it impossible to have null values in collections, since it uses null as a "poison pill" to detect the end of the iteration.

In the very very rare cases two threads share an iterator, you just need to wrap it inside some custom class and synchronize the access to the iterator, to make the check-then-act operation atomic. This is needed anyway since, even if the iterator just had one method, the backing collection (ArrayList in your example) is not thread-safe.

Answer 2

Your first suggestion is poor design because it relies on throwing and catching an exception for a condition that is known to eventually happen. Exceptions are rather expensive, and are meant only for "exceptional" situations which should not normally occur.

Your second suggestion doesn't take into account that Iterables can have null elements.

As for the thread safety bit, yes standard Iterators tend not to be thread safe and a custom implementation with added overhead would be necessary. This is true for most Java structures. As JB Nizet notes, it's more a matter of the Iterable structure being thread-safe before its Iterator can be.

Answer 3

For improved source code clarity, use (example with a collection of Strings)

Iterable<String> values = ... // typically a Collection (List, Set...)

for (String value : values) {
    // do something with the value
}

I concur with previous replies about null-bounded collections, loop control with exceptions (which is atrocious form) and thread safety.

Of your suggestions, null-bounding the collection is the least unwise, especially if you have a "no nulls" policy in your code. However it's very unidiomatic Java (edit: and breaks the contract of the Iterator interface), so liable to confuse future maintainers of the code (edit: and possibly cause subtle and/or unexpected bugs).