2010-04-07 3 views
4

Это известная проблема? Мне не удалось найти результаты поиска.Проблемы с повторным итератором ServiceLoader

При повторном выполнении ServiceLoader, когда итерация уже выполняется, первая итерация будет прервана. Например, предполагая, что существует, по крайней мере, две реализации Foo, следующий код будет терпеть неудачу с AssertionError:

ServiceLoader<Foo> loader = ServiceLoader.load(Foo.class); 
Iterator<Foo> iter1 = loader.iterator(); 
iter1.next(); 

Iterator<Foo> iter2 = loader.iterator(); 
while (iter2.hasNext()) { 
    iter2.next(); 
} 

assert iter1.hasNext(); 

Это только кажется, произойдет, если второй итератор действительно заканчивается. Код может преуспеть в этом варианте, например:

ServiceLoader<Foo> loader = ServiceLoader.load(Foo.class); 
Iterator<Foo> iter1 = loader.iterator(); 
iter1.next(); 

Iterator<Foo> iter2 = loader.iterator(); 
iter2.next(); 

assert iter1.hasNext(); 

Это ошибка или функция? : p

Есть ли билет для этого уже в любом месте?

+0

Вы пытались найти базу данных об ошибках? –

+0

Да, но ничего не найдено – buge

+0

Итак, нормальный ход действий при поиске ошибки без отчета об ошибке будет представлять отчет об ошибке. –

ответ

2

Это может быть ошибка. Я думаю, что это так, потому что iterator.next() вызывает next() на той же ссылке ленивого итератора внутри. Это поведение нарушает «Принцип наименьшего удивления»

+3

@ring: это очень возможная причина, но как это не ошибка? Ничто в документации не говорит о том, что вы можете называть 'iterator()' только один раз или что несколько «итераторов» каким-то образом зависят друг от друга. –

+0

Это может быть ошибка, отредактированный мой ответ. Я скорее подумал, почему нужно иметь несколько итераторов на ServiceLoader. Это нарушает «Принцип наименьшего удивления» по сравнению с «Итераторами» в другом месте Java –

+0

Почти год спустя Sun^H^H^H Oracle до сих пор не рассмотрела ошибку, которую я подал. Я отметил ваш ответ как принятый ответ. – buge

Смежные вопросы