Come posso copiare in sicurezza le raccolte?

In passato, ho detto di copiare in sicurezza una raccolta facendo qualcosa del tipo:

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

o

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

Ma questi costruttori "copia", metodi e flussi di creazione statici simili, sono davvero sicuri e dove sono specificate le regole? Con sicurezza intendo che le garanzie di integrità semantica di base offerte dal linguaggio Java e dalle raccolte vengono applicate contro un chiamante malintenzionato, supponendo che siano supportate da un ragionevole SecurityManagere che non vi siano difetti.

Sono felice con il metodo di lancio ConcurrentModificationException, NullPointerException, IllegalArgumentException, ClassCastException, ecc, o forse anche appeso.

Ho scelto Stringcome esempio di argomento di tipo immutabile. Per questa domanda, non mi interessano le copie profonde per raccolte di tipi mutabili che hanno i propri gotchas.

(Per essere chiari, ho esaminato il codice sorgente OpenJDK e ho una sorta di risposta per ArrayListe TreeSet.)

Non esiste una protezione reale contro il codice intenzionalmente dannoso in esecuzione all'interno della stessa JVM nelle normali API, come l'API Collection.

Come si può facilmente dimostrare:

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]

Come puoi vedere, aspettarsi List<String>che a non garantisca effettivamente un elenco di Stringistanze. A causa della cancellazione dei tipi e dei tipi non elaborati, non è nemmeno possibile una correzione sul lato dell'implementazione dell'elenco.

L'altra cosa, di cui puoi incolpare ArrayListil costruttore, è la fiducia nell'implementazione della raccolta in entrata toArray. TreeMapnon è influenzato allo stesso modo, ma solo perché non c'è un tale guadagno in termini di prestazioni dal passaggio dell'array, come nella costruzione di un ArrayList. Nessuna delle due classi garantisce una protezione nel costruttore.

Normalmente, non ha senso tentare di scrivere codice assumendo un codice intenzionalmente dannoso dietro ogni angolo. C'è troppo che può fare per proteggersi da tutto. Tale protezione è utile solo per il codice che incapsula realmente un'azione che potrebbe consentire a un chiamante malintenzionato di accedere a qualcosa, a cui non potrebbe già accedere senza questo codice.

Se hai bisogno di sicurezza per un determinato codice, usa

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);
    }
}

Quindi, puoi essere sicuro che newStrscontiene solo stringhe e non può essere modificato da altro codice dopo la sua costruzione.

Oppure utilizzare List<String> newStrs = List.of(strs.toArray(new String[0]));con Java 9 o versioni successive
Si noti che Java 10 List.copyOf(strs)fa lo stesso, ma la sua documentazione non afferma che è garantito che non si fidi del toArraymetodo della raccolta in entrata . Quindi chiamare List.of(…), che sicuramente farà una copia nel caso restituisca un elenco basato su array, è più sicuro.

Poiché nessun chiamante può modificare il modo in cui funziona, le matrici funzionano, scaricando la raccolta in arrivo in una matrice, seguita dal popolamento della nuova raccolta con essa, renderà sempre sicura la copia. Poiché la raccolta può contenere un riferimento all'array restituito, come dimostrato sopra, potrebbe modificarlo durante la fase di copia, ma non può influire sulla copia nella raccolta.

Pertanto, eventuali controlli di coerenza devono essere eseguiti dopo che l'elemento particolare è stato recuperato dall'array o sull'insieme risultante nel suo insieme.

Preferirei lasciare queste informazioni nei commenti, ma non ho abbastanza reputazione, scusa :) Cercherò di spiegarle il più dettagliatamente possibile.

Invece di qualcosa come il constmodificatore usato in C ++ per contrassegnare le funzioni membro che non dovrebbero modificare il contenuto degli oggetti, in Java originariamente veniva usato il concetto di "immutabilità". L'incapsulamento (o OCP, principio aperto-chiuso) doveva proteggere da eventuali mutazioni (cambiamenti) inattese di un oggetto. Ovviamente l'API di riflessione fa un passo avanti; l'accesso diretto alla memoria fa lo stesso; si tratta di sparare alla propria gamba :)

java.util.Collectionè di per sé un'interfaccia mutabile: ha un addmetodo che dovrebbe modificare la raccolta. Naturalmente il programmatore può racchiudere la raccolta in qualcosa che genererà ... e tutte le eccezioni di runtime accadranno perché un altro programmatore non è stato in grado di leggere javadoc, il che afferma chiaramente che la raccolta è immutabile.

Ho deciso di utilizzare il java.util.Iterabletipo per esporre la raccolta immutabile nelle mie interfacce. Semanticamente Iterablenon ha una tale caratteristica di raccolta come la "mutabilità". Tuttavia (molto probabilmente) sarai in grado di modificare le raccolte sottostanti attraverso gli stream.

JIC, per esporre le mappe in modo immutabile si java.util.Function<K,V>può usare (il getmetodo della mappa si adatta a questa definizione)