Есть задача, когда нужно последоватльно идти по елементам коллекции и сравнивать "хвост" от элемента до конца коллекции.

Как в java клонировать итератор, чтобы одним идти по элементам, а за счет его клонов анализировать "хвост"?

Здравствуйте, Hard_Club, Вы писали:

H_C>Есть задача, когда нужно последоватльно идти по елементам коллекции и сравнивать "хвост" от элемента до конца коллекции.

H_C>Как в java клонировать итератор, чтобы одним идти по элементам, а за счет его клонов анализировать "хвост"?

Iterator никак.

ListIterator можно так:

        List<Integer> list = ...;
        ListIterator<Integer> i = list.listIterator();
        while (i.hasNext()) {
            Integer x = i.next();
            ListIterator<Integer> j = list.listIterator(i.nextIndex());
            while (j.hasNext()) {
                Integer y = j.next();
            }
        }

но для LinkedList это будет не очень быстро. Быстрей вроде никак.

Лучше всего скопировать нужную коллекцию в массив и использовать обычные индексы.

vsb>но для LinkedList это будет не очень быстро. Быстрей вроде никак.

А почему для LinkedList это будет не очень быстро?

Здравствуйте, Hard_Club, Вы писали:

vsb>>но для LinkedList это будет не очень быстро. Быстрей вроде никак.

H_C>А почему для LinkedList это будет не очень быстро?

            ListIterator<Integer> j = list.listIterator(i.nextIndex());

Эта строчка возвращает итератор на элемент, находящийся в указанной позиции. Если у нас LinkedList из миллиона элементов, а мы просим итератор на элемент с индексом 400 000, то нам надо проитерироваться 400 000 раз с начала списка, чтобы вернуть такой итератор. Хотя теоретически можно было бы вернуть итератор моментально, скопировав поля, но в JDK этого не реализовано. Разве что через рефлексию копировать поля, но я бы не стал такой метод рекомендовать, разве что нет других вариантов вообще.

Здравствуйте, vsb, Вы писали:

vsb>Эта строчка возвращает итератор на элемент, находящийся в указанной позиции. Если у нас LinkedList из миллиона элементов, а мы просим итератор на элемент с индексом 400 000, то нам надо проитерироваться 400 000 раз с начала списка, чтобы вернуть такой итератор. Хотя теоретически можно было бы вернуть итератор моментально, скопировав поля, но в JDK этого не реализовано. Разве что через рефлексию копировать поля, но я бы не стал такой метод рекомендовать, разве что нет других вариантов вообще.
Скопировав какие поля?

Здравствуйте, devcoach, Вы писали:

vsb>>Эта строчка возвращает итератор на элемент, находящийся в указанной позиции. Если у нас LinkedList из миллиона элементов, а мы просим итератор на элемент с индексом 400 000, то нам надо проитерироваться 400 000 раз с начала списка, чтобы вернуть такой итератор. Хотя теоретически можно было бы вернуть итератор моментально, скопировав поля, но в JDK этого не реализовано. Разве что через рефлексию копировать поля, но я бы не стал такой метод рекомендовать, разве что нет других вариантов вообще.
D>Скопировав какие поля?

    private class ListItr implements ListIterator<E> {
        private Node<E> lastReturned;
        private Node<E> next;
        private int nextIndex;
        private int expectedModCount = modCount;

вот эти.

Вот рабочий пример, если интересно.

package test;

import java.lang.reflect.Constructor;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import java.util.*;

public class ListTest {
    public static void main(String[] args) {
        LinkedList<Integer> list = new LinkedList<Integer>();
        list.add(1);
        list.add(2);
        list.add(3);
        Iterator<Integer> i = list.iterator();
        while (i.hasNext()) {
            Iterator<Integer> j = copyIterator(list, i);
            Integer x = i.next();
            if (j != null) {
                while (j.hasNext()) {
                    Integer y = j.next();
                    System.out.println(x + " " + y);
                }
            }
        }
    }

    private static <T> Iterator<T> copyIterator(LinkedList<T> list, Iterator<T> i) {
        try {
            Class<?> iteratorClass = i.getClass();
            Constructor<?> constructor = iteratorClass.getDeclaredConstructors()[0];
            constructor.setAccessible(true);
            Object result = constructor.newInstance(list, list.size());
            for (Field field : iteratorClass.getDeclaredFields()) {
                if (!Modifier.isFinal(field.getModifiers())) {
                    field.setAccessible(true);
                    field.set(result, field.get(i));
                }
            }
            @SuppressWarnings("unchecked") Iterator<T> resultIterator = (Iterator<T>) result;
            return resultIterator;
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }
}

Маньяки

Здравствуйте, Hard_Club, Вы писали:

H_C>Маньяки

Да — но так не надо делать.

когда вообще стоит что-то делать через reflection?

Здравствуйте, Hard_Club, Вы писали:

H_C>когда вообще стоит что-то делать через reflection?

1. например dependency injection.

2. когда задачи не решаются без reflection-на (не ваш вариант, используйте ArrayList — делайте итерацию по индексам).
LinkedList это рудимент: занимает больше памяти для хранения коллекции, и нету RandomAccess. Преимуществ нет по сравнению с ArrayList.

руками что-ли. єто же framework делает

Здравствуйте, Hard_Club, Вы писали:

H_C>когда вообще стоит что-то делать через reflection?

В данном случае проблема не в reflection, как таковом (в нём то проблем нет, он работает надёжно), а в том, что мы подсмотрели реализацию в JDK и написали свой метод исходя из этой реализации. Если завтра в LinkedList поменяется реализация (а это может быть в абсолютно минорном обновлении), то есть все шансы, что этот код перестанет работать.

vsb>В данном случае проблема не в reflection, как таковом (в нём то проблем нет, он работает надёжно), а в том, что мы подсмотрели реализацию в JDK и написали свой метод исходя из этой реализации. Если завтра в LinkedList поменяется реализация (а это может быть в абсолютно минорном обновлении), то есть все шансы, что этот код перестанет работать.

просто считается, что в коде должно быть как можно меньше reflection

Здравствуйте, Hard_Club, Вы писали:

vsb>>В данном случае проблема не в reflection, как таковом (в нём то проблем нет, он работает надёжно), а в том, что мы подсмотрели реализацию в JDK и написали свой метод исходя из этой реализации. Если завтра в LinkedList поменяется реализация (а это может быть в абсолютно минорном обновлении), то есть все шансы, что этот код перестанет работать.

H_C>просто считается, что в коде должно быть как можно меньше reflection

Ну reflection во-первых немного медленней других способов, во-вторых IDE с ним не может нормально работать. Если можно задачу решить нормально без него, естественно лучше так и делать.

Здравствуйте, Hard_Club, Вы писали:

H_C>руками что-ли. єто же framework делает

А если свой фрейворк пишешь?

V>А если свой фрейворк пишешь?

ну это вообще