Why does Scanner implement Iterator?

Question

I was just wondering why java.util.Scanner implements java.util.Iterator?

Scanner implements the remove method and throws an UnsupportedOperationExcept

Answer 1

It's just not a supported method. To avoid implementing it that way would require a similar interface without a remove method. Is it good design to create multiple similar interfaces just to avoid a method that throws NotImplementedException?

Anyone using a Scanner knows (or will soon know) that the remove() method can't be used, so it really has no practical effect. It could also be a no-op, since effectively the item is removed, just not due to remove(), but it's probably clearer to throw an exception.

Answer 2

I'd say yes, it's a design flaw. The flaw is within Iterator. This issue could be thrown in the same category as attempting to create an immutable Collection implementation.

It violates the Interface Segregation Principle and forces the developers to include a corner case into the JavaDocs (the infamous UnsupportedOperationException) to avoid violating the Liskov Subsitution Principle. You'll find this in Collection#remove methods aswell.

---

I believe design could be improved by decomposing the interface, segregating hasNext() and next() into a new (immutable) interface and letting the (mutable) Iterator interface derive from it :

interface Traversable<E> {
    boolean hasNext();
    E next();
}

interface Iterator<E> extends Traversable<E> {
    void remove();
}

final class Scanner implements Traversable<String> {

}

Better names could definitely be used. Please don't down this post due to my bad naming choices.

Why does Scanner implement Iterator in the first place?

Scanner is not an iterator in the sense of traversing a collection. But the idea of a Scanner is to supply it input to be "scanned", which in a sense is iterating over something (the characters in a String).

I can see why Scanner would implement Iterator (you were asking for a use case). For example, if you wanted to create your own Iterable type to iterate over a String specifying a delimiter:

class ScannerWrapper implements Iterable<E> {
    public Scanner scanner;

    public ScannerWrapper(Scanner scanner) {
        this.scanner = scanner;
    }

    public Iterator<String> iterator() {
        return scanner;
    }
} 

Scanner scanner = new Scanner("one,two,three");
scanner.useDelimiter(",");
ScannerWrapper wrapper = new ScannerWrapper(scanner);

for(String s : wrapper) {
    System.out.println(s);
}

But this would have also worked if the JDK supported a Traversable type and allowed enhanced loops to accept Traversable items, since removing from a collection in this fashion may throw a ConcurrentModificationException, which leads to using an iterator instead.

Conclusion

So is it good design? Nope. It violates ISP and results in cluttered contracts. This is simply a giagantic code smell. The real problem is the language's lack of support for immutability, which should allow developers to specify whether a behavior should mutate state, allowing behavioral contracts to be stripped of their mutability. Or something along those lines..

The JDK is filled with stuff like this (bad design choices, such as exposing length for arrays and attempts at an ImmutableMap I mentioned above), and changing it now would result in breaking code.

Answer 3

Because implementing iterator allows the scanner to be used wherever a read only iterator can be used.

Furthermore it does implement the contract. From the Iterator documentation (emphasis mine):

remove() Removes from the underlying collection the last element returned by this iterator (optional operation).

Answer 4

For an official answer, see the Collections Framework Overview. Scroll down to the bottom for Design Goals.

To keep the number of core interfaces small, the interfaces do not attempt to capture such subtle distinctions as mutability, modifiability, and resizability. Instead, certain calls in the core interfaces are optional, enabling implementations to throw an UnsupportedOperationException to indicate that they do not support a specified optional operation. Collection implementers must clearly document which optional operations are supported by an implementation.

As previous answers have pointed out, the Collections framework could uphold Liskov Substition by decomposing its interfaces into numerous, smaller interfaces. That approach was considered and rejected, in order to minimize the number of core interfaces in the framework.