Raccolte immutabili Java

Dalla documentazione di Java 1.6 Collection Framework :

Collezioni che non supportano alcuna operazione di modifica (quali add, removee clear) sono indicati come immodificabile . [...] Le collezioni che garantiscono inoltre che nessun cambiamento nell'oggetto Collection sarà mai visibile sono indicate come immutabili .

Il secondo criterio mi confonde un po '. Dato che la prima raccolta non è modificabile e supponendo che il riferimento alla raccolta originale sia stato eliminato, quali sono le modifiche a cui si fa riferimento nella seconda riga? Si riferisce ai cambiamenti negli elementi contenuti nella collezione, cioè allo stato degli elementi?

Seconda domanda:
affinché una collezione sia immutabile, come si fa a fornire le garanzie aggiuntive specificate? Se lo stato di un elemento nella raccolta viene aggiornato da un thread, è sufficiente per l'immutabilità che quegli aggiornamenti nello stato non siano visibili sul thread che contiene la raccolta immutabile?

Affinché una collezione sia immutabile, come si fa a fornire le garanzie aggiuntive specificate?

Le raccolte non modificabili sono in genere viste di sola lettura (wrapper) di altre raccolte. Non puoi aggiungerli, rimuoverli o cancellarli, ma la raccolta sottostante può cambiare.

Le raccolte immutabili non possono essere modificate affatto - non racchiudono un'altra raccolta - hanno i propri elementi.

Ecco una citazione da guava's ImmutableList

A differenza di Collections.unmodifiableList(java.util.List<? extends T>), che è una visualizzazione di una raccolta separata che può ancora cambiare, un'istanza di ImmutableListcontiene i propri dati privati ​​e non cambierà mai.

Quindi, in pratica, per ottenere una raccolta immutabile da una mutabile, è necessario copiare i suoi elementi nella nuova raccolta e non consentire tutte le operazioni.

La differenza è che non puoi avere un riferimento a una raccolta immutabile che consente modifiche. Le raccolte non modificabili non sono modificabili tramite quel riferimento , ma qualche altro oggetto può puntare agli stessi dati tramite i quali può essere modificato.

per esempio

List<String> strings = new ArrayList<String>();
List<String> unmodifiable = Collections.unmodifiableList(strings);
unmodifiable.add("New string"); // will fail at runtime
strings.add("Aha!"); // will succeed
System.out.println(unmodifiable);

Collection<String> c1 = new ArrayList<String>();
c1.add("foo");
Collection<String> c2 = Collections.unmodifiableList(c1);

c1è mutabile (cioè né immodificabile né immutabile ). non
c2 è modificabile : non può essere modificato da solo, ma se in seguito cambio c1allora quel cambiamento sarà visibile in c2.

Questo perché c2è semplicemente un wrapper c1e non è davvero una copia indipendente. Guava fornisce l' ImmutableListinterfaccia e alcune implementazioni. Questi funzionano creando effettivamente una copia dell'input (a meno che l'input non sia una raccolta immutabile di per sé).

Per quanto riguarda la tua seconda domanda:

La mutabilità / immutabilità di una collezione non dipende dalla mutabilità / immutabilità degli oggetti in essa contenuti. La modifica di un oggetto contenuto in una raccolta non conta come una "modifica della raccolta" per questa descrizione. Ovviamente se hai bisogno di una raccolta immutabile, di solito vuoi che contenga anche oggetti immutabili.

Ora java 9 ha metodi di fabbrica per Immutable List, Set, Map e Map.Entry.

In Java SE 8 e versioni precedenti, è possibile utilizzare metodi di utilità della classe Collections come unmodifiableXXX per creare oggetti Collection immutabili.

Tuttavia, questi metodi Collections.unmodifiableXXX sono un approccio molto noioso e dettagliato. Per superare queste carenze, Oracle corp ha aggiunto un paio di metodi di utilità alle interfacce List, Set e Map.

Ora in java 9: ​​- Le interfacce List e Set hanno metodi "of ()" per creare un elenco immutabile vuoto o non vuoto o oggetti Set come mostrato di seguito:

Esempio di elenco vuoto

List immutableList = List.of();

Esempio di elenco non vuoto

List immutableList = List.of("one","two","three");

Credo che il punto qui sia che anche se una collezione è immodificabile, ciò non garantisce che non possa cambiare. Prendiamo ad esempio una raccolta che elimina gli elementi se sono troppo vecchi. Non modificabile significa semplicemente che l'oggetto che contiene il riferimento non può cambiarlo, non che non può cambiare. Un vero esempio di questo è il Collections.unmodifiableListmetodo. Restituisce una vista non modificabile di un elenco. Il riferimento List passato a questo metodo è ancora modificabile e quindi l'elenco può essere modificato da qualsiasi detentore del riferimento passato. Ciò può causare ConcurrentModificationExceptions e altri problemi.

Immutabile, significa che in nessun modo la collezione può essere modificata.

Seconda domanda: una raccolta immutabile non significa che gli oggetti contenuti nella raccolta non cambieranno, ma solo che la raccolta non cambierà nel numero e nella composizione degli oggetti che contiene. In altre parole, l'elenco dei riferimenti della raccolta non cambierà. Ciò non significa che gli interni dell'oggetto a cui si fa riferimento non possano cambiare.

Pure4J supporta ciò che stai cercando , in due modi.

Innanzitutto, fornisce @ImmutableValueun'annotazione, in modo che tu possa annotare una classe per dire che è immutabile. C'è un plug-in Maven che ti consente di controllare che il tuo codice sia effettivamente immutabile (uso di finalecc.).

In secondo luogo, fornisce le raccolte persistenti di Clojure (con l'aggiunta di generici) e garantisce che gli elementi aggiunti alle raccolte siano immutabili. Le prestazioni di questi sono apparentemente piuttosto buone. Le raccolte sono tutte immutabili, ma implementano le interfacce (e generiche) delle raccolte Java per l'ispezione. La mutazione restituisce nuove raccolte.

Disclaimer: sono lo sviluppatore di questo