Y a-t-il des classes Java standard qui implémentent Iterable sans implémenter Collection?

bien qu'il n'y ait aucune classe qui serait immédiatement adapté à vos besoins et être intuitif pour les lecteurs de votre code de test, vous pouvez facilement créer votre propre classe anonyme qui est facile à comprendre:

static Iterable<Integer> range(final int from, final int to) {
    return new Iterable<Integer>() {
        public Iterator<Integer> iterator() {
            return new Iterator<Integer>() {
                int current = from;
                public boolean hasNext() { return current < to; }
                public Integer next() {
                    if (!hasNext()) { throw new NoSuchElementException(); }
                    return current++;
                }
                public void remove() { /*Optional; not implemented.*/ }
            };
        }
    };
}

Démo.

cette implémentation est anonyme, et elle n'implémente pas Collection<Integer> . D'autre part, il produit un non-vide énumérable séquence d'entiers, que vous pouvez contrôler complètement.

Kludgy, Oui, mais je pense que le code

Collection<Integer> _keys;
if (keys instanceof Collection) {
    _keys = (Collection<Integer>) keys;
} else {
    _keys = Lists.newArrayList(keys);
}

est parfaitement sain. L'interface Collection<T> étend Iterable<T> et vous n'êtes pas autorisé à implémenter la même interface avec 2 paramètres de type différents, il n'y a donc pas moyen qu'une classe puisse implémenter Collection<String> et Iterable<Integer> , par exemple.

la classe Integer est finale, de sorte que la différence entre Iterable<? extends Integer> et Iterable<Integer> est largement académique.

pris ensemble, les deux derniers paragraphes prouvent que si quelque chose est à la fois un Iterable<? extends Integer> et un Collection , il doit s'agir d'un Collection<Integer> . Par conséquent, votre code est garanti pour être sûr. Le compilateur ne peut pas être sûr de cela donc vous pouvez supprimer l'avertissement en écrivant

@SuppressWarnings("unchecked")

au-dessus de la déclaration. Vous devez également inclure un commentaire par les annotations pour expliquer pourquoi le code est sûr.

quant à la question de savoir s'il y a toutes les classes qui implémentent Iterable , mais pas Collection , comme d'autres l'ont souligné, la réponse est oui. Cependant, je pense que ce que vous demandez vraiment, c'est s'il y a un intérêt à avoir deux interfaces. Beaucoup d'autres l'ont demandé. Souvent, lorsqu'une méthode a un argument Collection (par exemple addAll() ), il pourrait, et devrait probablement, être un Iterable .

Modifier

@Andreas a souligné dans les commentaires que Iterable n'a été introduit Qu'en Java 5, alors que Collection a été introduit en Java 1.2, et la plupart des méthodes existantes prenant un Collection ne pouvait pas être modifié pour prendre un Iterable pour des raisons de compatibilité.

pour répondre À la question que par le titre:

y a-t-il des classes Java standard qui implémentent Iterable sans implémenter Collection ?

à Partir du texte:

S'il y a des classes qui peuvent implémenter Iterable<T> qui n'implémentent pas aussi Collection<T> ?

réponse:

Oui

voir la page javadoc suivante: https://docs.oracle.com/javase/8/docs/api/java/lang/class-use/Iterable.html

toute section qui dit Classes in XXX that implement Iterable , listera les classes Java standard implémentant l'interface. Beaucoup d'entre eux ne mettent pas en œuvre Collection .

dans les API du cœur, les seuls types qui sont Iterable mais pas Collection --

interface java.nio.file.Path

interface java.nio.file.DirectoryStream
interface java.nio.file.SecureDirectoryStream

class java.util.ServiceLoader

class java.sql.SQLException (and subclasses)

ce sont sans doute de mauvaises conceptions.

comme mentionné dans @bayou.io ' S réponse, l'une de ces implémentations pour Iterable est la nouvelle classe Path pour le système de fichiers transversal introduit en Java 7.

si vous êtes sur Java 8, Iterable a été modifié avec (i.e. donné une méthode default ) spliterator() (faites attention à sa note de mise en œuvre ), qui vous permet de l'utiliser en conjonction avec StreamSupport :

public static <T> Collection<T> convert(Iterable<T> iterable) {
    // using Collectors.toList() for illustration, 
    // there are other collectors available
    return StreamSupport.stream(iterable.spliterator(), false)
                        .collect(Collectors.toList());
}

cela vient à la légère dépense que tout argument qui est déjà une mise en œuvre Collection passe par une opération de flux et de collecte inutile. Vous ne devriez probablement l'utiliser que si le désir d'une approche standardisée JDK-seulement l'emporte sur le succès potentiel de performance, par rapport à votre casting original ou des méthodes basées sur la goyave, ce qui est probablement discutable puisque vous utilisez déjà le CacheLoader De Goyave .

pour tester ceci, considérez cet extrait et la sortie de l'échantillon:

// Snippet
System.out.println(convert(Paths.get(System.getProperty("java.io.tmpdir"))));
// Sample output on Windows
[Users, MyUserName, AppData, Local, Temp]