¿Cómo puedo copiar colecciones de forma segura?

En el pasado, he dicho que copiar una colección de manera segura haga algo como:

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

Pero, ¿son estos constructores de "copia", métodos y flujos de creación estáticos similares, realmente seguros y dónde se especifican las reglas? Por seguro, quiero decir, son las garantías básicas de integridad semántica ofrecidas por el lenguaje Java y las colecciones aplicadas contra un llamador malicioso, suponiendo SecurityManagerque esté respaldado por un razonable y que no haya fallas.

Estoy contento con el lanzamiento método ConcurrentModificationException, NullPointerException, IllegalArgumentException, ClassCastException, etc, o tal vez incluso colgado.

He elegido Stringcomo ejemplo un argumento de tipo inmutable. Para esta pregunta, no me interesan las copias profundas para colecciones de tipos mutables que tienen sus propios trucos.

(Para ser claros, he mirado el código fuente de OpenJDK y tengo algún tipo de respuesta para ArrayListy TreeSet).

No existe una protección real contra el código intencionalmente malicioso que se ejecuta dentro de la misma JVM en las API normales, como la API de recopilación.

Como se puede demostrar fácilmente:

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]

Como puede ver, esperar un List<String>no garantiza realmente obtener una lista de Stringinstancias. Debido a la eliminación de tipos y tipos sin formato, ni siquiera hay una solución posible en el lado de implementación de la lista.

La otra cosa de la que puede culpar ArrayListal constructor es la confianza en la toArrayimplementación de la colección entrante . TreeMapno se ve afectado de la misma manera, sino solo porque no hay tal ganancia de rendimiento al pasar la matriz, como en la construcción de un ArrayList. Ninguna clase garantiza una protección en el constructor.

Normalmente, no tiene sentido intentar escribir código suponiendo código intencionalmente malicioso en cada esquina. Hay demasiado que puede hacer para protegerse contra todo. Dicha protección solo es útil para el código que realmente encapsula una acción que podría otorgarle a una persona que llama maliciosa acceso a algo, ya que no podría acceder sin este código.

Si necesita seguridad para un código en particular, use

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

Luego, puede estar seguro de que newStrssolo contiene cadenas y no puede ser modificado por otro código después de su construcción.

O úselo List<String> newStrs = List.of(strs.toArray(new String[0]));con Java 9 o más reciente
Tenga en cuenta que Java 10's List.copyOf(strs)hace lo mismo, pero su documentación no indica que está garantizado que no confíe en el toArraymétodo de la colección entrante . Entonces List.of(…), llamar , que definitivamente hará una copia en caso de que devuelva una lista basada en una matriz, es más seguro.

Como ninguna persona que llama puede alterar la forma, las matrices funcionan, volcar la colección entrante en una matriz, seguido de llenar la nueva colección con ella, siempre hará que la copia sea segura. Dado que la colección puede contener una referencia a la matriz devuelta como se demostró anteriormente, podría alterarla durante la fase de copia, pero no puede afectar la copia en la colección.

Por lo tanto, cualquier verificación de coherencia debe realizarse después de que el elemento particular se haya recuperado de la matriz o de la colección resultante en su conjunto.

Preferiría dejar esta información en el comentario, pero no tengo suficiente reputación, lo siento :) Trataré de explicarla tan detalladamente como pueda.

En lugar de algo así como un constmodificador utilizado en C ++ para marcar funciones miembro que no deben modificar el contenido del objeto, en Java originalmente se utilizó el concepto de "inmutabilidad". Se suponía que la encapsulación (u OCP, principio abierto-cerrado) protegía contra cualquier mutación inesperada (cambio) de un objeto. Por supuesto, la API de reflexión explica esto; el acceso directo a la memoria hace lo mismo; eso es más sobre disparar una pierna :)

java.util.Collectionen sí es una interfaz mutable: tiene un addmétodo que se supone que modifica la colección. Por supuesto, el programador puede envolver la colección en algo que arrojará ... y todas las excepciones de tiempo de ejecución sucederán porque otro programador no pudo leer javadoc, que claramente dice que la colección es inmutable.

Decidí usar java.util.Iterabletype para exponer una colección inmutable en mis interfaces. Semánticamente Iterableno tiene una característica de colección como la "mutabilidad". Aún así (muy probablemente) podrá modificar colecciones subyacentes a través de secuencias.

java.util.Function<K,V>Se puede usar JIC para exponer mapas de manera inmutable (el getmétodo del mapa se ajusta a esta definición)