Насколько я могу судить, причина может быть найдена в той части Javadoc, которую вы не цитировали (выделено ниже моей):
Итератор для списков, который позволяет программисту обходить список в любом направлении, изменять список во время итерации ...
Видите ли, цель состоит в том, чтобы разрешить использование во время изменения списка. Возможные модификации, по-видимому, включают удаление элементов.
Теперь подумайте, что произойдет, если мы удалим элемент, который был бы current()
для итератора - предполагая, что итератор будет иметь представление о текущем элементе? В этом контексте способ реализовать его без представления о текущем элементе имеет для меня довольно хороший смысл - потому что в этом случае итератору не нужно беспокоиться об удалении элементов.
Это важно отметить , что Javadoc не требует реализации интерфейса потокобезопасной.
- Из-за этого не следует ожидать правильной обработки изменений, выполненных из разных потоков - для этого реализация должна будет предоставить дополнительные средства для синхронизации доступа, гарантии видимости и т. Д., Как указано в модели памяти Java для JSR 133 .
То, на что способен ListIterator, обрабатывает изменения, сделанные из одного и того же потока при итерации. Не все итераторы такие, Javadocs ConcurrentModificationException специально предупреждают об этом:
... Обратите внимание, что это исключение не всегда указывает на то, что объект был одновременно изменен другим потоком. Если один поток выдает последовательность вызовов методов, которая нарушает контракт объекта, объект может вызвать это исключение. Например, если поток изменяет коллекцию напрямую, в то время как он выполняет итерацию по коллекции с помощью итератора, работающего без сбоев, итератор сгенерирует это исключение ...