Quando o loop for forçado (loop foreach) foi adicionado ao Java, ele foi criado para funcionar com um destino de uma matriz ouIterable.

for ( T item : /*T[] or Iterable<? extends T>*/ ) {
    //use item
}

Isso funciona muito bem para as classes Collection que implementam apenas um tipo de iteração e, portanto, têm um únicoiterator() método.

Mas me sinto incrivelmente frustrado no momento em que quero usar um iterador não padrão de uma classe Collection. Por exemplo, recentemente eu estava tentando ajudar alguém a usar umDeque como um LIFO / pilha, mas depois imprima os elementos na ordem FIFO. Fui forçado a fazer isso:

for (Iterator<T> it = myDeque.descendingIterator(); it.hasNext(); ) {
   T item = it.next();
   //use item
}

Perco as vantagens do loop for-each. Não se trata apenas de pressionar as teclas. Não gosto de expor o iterador se não for necessário, pois é fácil cometer o erro de chamarit.next() duas vezes etc.

Agora, idealmente, acho que o loop for-each deveria ter aceitado umIterator também. Mas isso não acontece. Então, existe uma maneira idiomática de usar o loop for-each nessas circunstâncias? Eu também adoraria ouvir sugestões que usam bibliotecas de coleções comuns como o Guava.

O melhor que posso apresentar na ausência de um método / classe auxiliar é:

for ( T item : new Iterable<T>() { public Iterator<T> iterator() { return myDeque.descendingIterator(); } } ) {
    //use item
}

O que não vale a pena usar.

Eu adoraria ver a goiaba ter algo comoIterables.wrap para fazer isso idiomático, mas não encontrou nada parecido. Obviamente, eu poderia rolar meu próprio wrapper Iterator por meio de um método de classe ou auxiliar. Alguma outra ideia?

Editar: Como observação lateral, alguém pode dar uma razão válida para o motivo do loop for aprimorado não ter sido capaz de aceitar apenas umIterator? Provavelmente seria um longo caminho para me fazer viver com o design atual.