Comment puis-je copier des collections en toute sécurité?

Dans le passé, j'ai dit que pour copier une collection en toute sécurité, faites quelque chose comme:

public static void doThing(List<String> strs) {
    List<String> newStrs = new ArrayList<>(strs);

ou

public static void doThing(NavigableSet<String> strs) {
    NavigableSet<String> newStrs = new TreeSet<>(strs);

Mais ces constructeurs de «copie», des méthodes de création statique similaires et des flux, sont-ils vraiment sûrs et où sont les règles spécifiées? Par sûr, j'entends les garanties d' intégrité sémantique de base offertes par le langage Java et les collections appliquées contre un appelant malveillant, en supposant SecurityManagerqu'elles soient sauvegardées par un raisonnable et qu'il n'y a pas de défauts.

Je suis heureux avec le lancement de la méthode ConcurrentModificationException, NullPointerException, IllegalArgumentException, ClassCastException, etc., ou peut - être même accroché.

J'ai choisi Stringcomme exemple d'argument de type immuable. Pour cette question, je ne suis pas intéressé par les copies complètes pour les collections de types mutables qui ont leurs propres pièges.

(Pour être clair, j'ai regardé le code source d'OpenJDK et j'ai une sorte de réponse pour ArrayListet TreeSet.)

Il n'y a pas de véritable protection contre le code intentionnellement malveillant exécuté dans la même JVM dans les API ordinaires, comme l'API Collection.

Comme on peut facilement le démontrer:

public static void main(String[] args) throws InterruptedException {
    Object[] array = { "foo", "bar", "baz", "and", "another", "string" };
    array[array.length - 1] = new Object() {
        @Override
        public String toString() {
            Collections.shuffle(Arrays.asList(array));
            return "string";
        }
    };
    doThing(new ArrayList<String>() {
        @Override public Object[] toArray() {
            return array;
        }
    });
}

public static void doThing(List<String> strs) {
    List<String> newStrs = new ArrayList<>(strs);

    System.out.println("made a safe copy " + newStrs);
    for(int i = 0; i < 10; i++) {
        System.out.println(newStrs);
    }
}

made a safe copy [foo, bar, baz, and, another, string]
[bar, and, string, string, another, foo]
[and, baz, bar, string, string, string]
[another, baz, and, foo, bar, string]
[another, bar, and, foo, string, and]
[another, baz, string, another, and, foo]
[string, and, another, foo, string, foo]
[baz, string, foo, and, baz, string]
[bar, another, string, and, another, baz]
[bar, string, foo, string, baz, and]
[bar, string, bar, another, and, foo]

Comme vous pouvez le voir, s'attendre à ce qu'une List<String>garantie n'obtienne pas réellement une liste d' Stringinstances. En raison de l'effacement des types et des types bruts, il n'y a même pas de correctif possible du côté de l'implémentation de la liste.

L'autre chose dont vous pouvez blâmer ArrayListle constructeur est la confiance dans l' toArrayimplémentation de la collection entrante . TreeMapn'est pas affecté de la même manière, mais uniquement parce qu'il n'y a pas un tel gain de performances en passant le tableau, comme dans la construction d'un ArrayList. Aucune des deux classes ne garantit une protection dans le constructeur.

Normalement, il est inutile d'essayer d'écrire du code en supposant du code intentionnellement malveillant à chaque coin de rue. Il y a trop à faire pour se protéger de tout. Une telle protection n'est utile que pour le code qui encapsule vraiment une action qui pourrait donner à un appelant malveillant l'accès à quelque chose, il ne pourrait pas déjà y accéder sans ce code.

Si vous avez besoin de sécurité pour un code particulier, utilisez

public static void doThing(List<String> strs) {
    String[] content = strs.toArray(new String[0]);
    List<String> newStrs = new ArrayList<>(Arrays.asList(content));

    System.out.println("made a safe copy " + newStrs);
    for(int i = 0; i < 10; i++) {
        System.out.println(newStrs);
    }
}

Ensuite, vous pouvez être sûr qu'il newStrsne contient que des chaînes et ne peut pas être modifié par un autre code après sa construction.

Ou utilisez List<String> newStrs = List.of(strs.toArray(new String[0]));avec Java 9 ou une version plus récente.
Notez que Java 10 List.copyOf(strs)fait de même, mais sa documentation n'indique pas qu'il est garanti de ne pas faire confiance à la toArrayméthode de la collection entrante . Donc, appeler List.of(…), qui fera certainement une copie au cas où il retournerait une liste basée sur un tableau, est plus sûr.

Étant donné qu'aucun appelant ne peut modifier la façon dont les tableaux fonctionnent, le vidage de la collection entrante dans un tableau, suivi du remplissage de la nouvelle collection avec elle, rendra toujours la copie sûre. Étant donné que la collection peut contenir une référence au tableau renvoyé, comme illustré ci-dessus, elle peut la modifier pendant la phase de copie, mais elle ne peut pas affecter la copie dans la collection.

Par conséquent, tout contrôle de cohérence doit être effectué après que l'élément particulier a été récupéré du tableau ou sur la collection résultante dans son ensemble.

Je préfère laisser ces informations en commentaire, mais je n'ai pas assez de réputation, désolé :) Je vais essayer de l'expliquer le plus verbeux possible.

Au lieu de quelque chose comme un constmodificateur utilisé en C ++ pour marquer les fonctions membres qui ne sont pas censées modifier le contenu des objets, en Java était à l'origine utilisé le concept d '"immuabilité". L'encapsulation (ou OCP, Open-Closed Principle) était censée protéger contre toute mutation (modification) inattendue d'un objet. Bien sûr, l'API de réflexion marche autour de cela; l'accès direct à la mémoire fait de même; c'est plus de tirer sur sa propre jambe :)

java.util.Collectionlui-même est une interface mutable: il a une addméthode qui est censée modifier la collection. Bien sûr, le programmeur peut envelopper la collection dans quelque chose qui déclenchera ... et toutes les exceptions d'exécution se produiront car un autre programmeur n'a pas pu lire javadoc qui indique clairement que la collection est immuable.

J'ai décidé d'utiliser le java.util.Iterabletype pour exposer la collection immuable dans mes interfaces. Sémantiquement Iterablen'a pas une telle caractéristique de collection que la "mutabilité". Vous pourrez toujours (très probablement) modifier les collections sous-jacentes via des flux.

JIC, pour exposer des cartes de manière immuable java.util.Function<K,V>peut être utilisé (la getméthode de la carte correspond à cette définition)