Java 9 introdujo nuevos métodos de fábrica para listas List.of:

List<String> strings = List.of("first", "second");

¿Cuál es la diferencia entre la opción anterior y la nueva? Es decir, cuál es la diferencia entre esto:

Arrays.asList(1, 2, 3);

y esto:

List.of(1, 2, 3);

Arrays.asListdevuelve una lista mutable mientras que la lista devuelta por List.ofes inmutable :

List<Integer> list = Arrays.asList(1, 2, null);
list.set(1, 10); // OK

List<Integer> list = List.of(1, 2, 3);
list.set(1, 10); // Fails with UnsupportedOperationException

Arrays.asListpermite elementos nulos mientras List.ofque no:

List<Integer> list = Arrays.asList(1, 2, null); // OK
List<Integer> list = List.of(1, 2, null); // Fails with NullPointerException

contains se comporta de manera diferente con nulos:

List<Integer> list = Arrays.asList(1, 2, 3);
list.contains(null); // Returns false

List<Integer> list = List.of(1, 2, 3);
list.contains(null); // Fails with NullPointerException

Arrays.asListdevuelve una vista de la matriz pasada, por lo que los cambios a la matriz también se reflejarán en la lista. Porque List.ofesto no es cierto:

Integer[] array = {1,2,3};
List<Integer> list = Arrays.asList(array);
array[1] = 10;
System.out.println(list); // Prints [1, 10, 3]

Integer[] array = {1,2,3};
List<Integer> list = List.of(array);
array[1] = 10;
System.out.println(list); // Prints [1, 2, 3]

Las diferencias entre Arrays.asListyList.of

Vea JavaDocs y esta charla de Stuart Marks (o versiones anteriores).

Usaré lo siguiente para los ejemplos de código:

List<Integer> listOf = List.of(...);
List<Integer> asList = Arrays.asList(...);
List<Integer> unmodif = Collections.unmodifiableList(asList);

Inmutabilidad estructural (O: inmodificabilidad)

Cualquier intento de cambiar estructuralmenteList.of resultará en un UnsupportedOperationException. Eso incluye operaciones como agregar , configurar y eliminar . Sin embargo, puede cambiar el contenido de los objetos en la lista (si los objetos no son inmutables), por lo que la lista no es "completamente inmutable".

Este es el mismo destino para las listas no modificables creadas con Collections.unmodifiableList. Solo esta lista es una vista de la lista original, por lo que puede cambiar si cambia la lista original.

Arrays.asListno es completamente inmutable, no tiene restricciones set.

listOf.set(1, "a");  // UnsupportedOperationException
unmodif.set(1, "a"); // UnsupportedOperationException
asList.set(1, "a");  // modified unmodif! unmodif is not truly unmodifiable

De manera similar, cambiar la matriz de respaldo (si la mantiene presionada) cambiará la lista.

La inmutabilidad estructural viene con muchos efectos secundarios relacionados con la codificación defensiva, la concurrencia y la seguridad que están más allá del alcance de esta respuesta.

Hostilidad nula

List.ofy cualquier colección desde Java 1.5 no se permite nullcomo elemento. Intentar pasar nullcomo un elemento o incluso una búsqueda resultará en un NullPointerException.

Dado que Arrays.asListes una colección de 1.2 (el marco de colecciones), permite nulls.

listOf.contains(null);  // NullPointerException
unmodif.contains(null); // allowed
asList.contains(null);  // allowed

Forma serializada

Dado que List.ofse introdujo en Java 9 y las listas creadas por este método tienen su propia forma serializada (binaria), no se pueden deserializar en versiones anteriores de JDK (sin compatibilidad binaria ). Sin embargo, puede eliminar / serializar con JSON, por ejemplo.

Identidad

Arrays.asListllamadas internas new ArrayList, lo que garantiza la desigualdad de referencia.

List.ofdepende de la implementación interna. Las instancias devueltas pueden tener igualdad de referencia, pero como esto no está garantizado, no puede confiar en ellas.

asList1 == asList2; // false
listOf1 == listOf2; // true or false

Vale la pena mencionar que las listas son iguales (vía List.equals) si contienen los mismos elementos en el mismo orden, independientemente de cómo fueron creadas o qué operaciones soportan.

asList.equals(listOf); // true i.f.f. same elements in same order

Implementación (advertencia: los detalles pueden cambiar según las versiones)

Si el número de elementos en la lista de List.ofes 2 o menos, los elementos se almacenan en campos de una clase especializada (interna). Un ejemplo es la lista que almacena 2 elementos (fuente parcial):

static final class List2<E> extends AbstractImmutableList<E> {
    private final E e0;
    private final E e1;

    List2(E e0, E e1) {
        this.e0 = Objects.requireNonNull(e0);
        this.e1 = Objects.requireNonNull(e1);
    }
}

De lo contrario, se almacenan en una matriz de forma similar a Arrays.asList.

Eficiencia de tiempo y espacio

Las List.ofimplementaciones que se basan en el campo (tamaño <2) funcionan un poco más rápido en algunas operaciones. Como ejemplos, size()puede devolver una constante sin obtener la longitud de la matriz y contains(E e)no requiere una sobrecarga de iteración.

La construcción de una lista no modificable vía List.oftambién es más rápida. Compare el constructor anterior con 2 asignaciones de referencia (e incluso la de una cantidad arbitraria de elementos) para

Collections.unmodifiableList(Arrays.asList(...));

que crea 2 listas más otros gastos generales. En términos de espacio, ahorra el UnmodifiableListenvoltorio más algunos centavos. En última instancia, los ahorros en el HashSetequivalente son más convincentes.

Tiempo de conclusión: utilícelo List.ofcuando desee una lista que no cambie y Arrays.asListcuando desee una lista que pueda cambiar (como se muestra arriba).

Resumamos las diferencias entre List.of y Arrays.asList

1. List.ofse puede utilizar mejor cuando el conjunto de datos es menor y sin cambios, mientras que Arrays.asListse puede utilizar mejor en el caso de un conjunto de datos grande y dinámico.

2. List.ofocupa mucho menos espacio de sobrecarga porque tiene una implementación basada en el campo y consume menos espacio de pila, tanto en términos de sobrecarga fija como por elemento. mientras que Arrays.asListocupa más espacio de sobrecarga porque durante la inicialización crea más objetos en el montón.

3. La colección devuelta por List.ofes inmutable y, por lo tanto, segura para subprocesos, mientras que la colección devuelta por Arrays.asListes mutable y no segura para subprocesos. (Las instancias de colección inmutables generalmente consumen mucha menos memoria que sus contrapartes mutables).

4. List.ofno permite elementos nulos mientras que Arrays.asListpermite elementos nulos .

Aparte de las respuestas anteriores, hay ciertas operaciones en las que ambos List::ofy Arrays::asListdifieren:

+----------------------+---------------+----------+----------------+---------------------+
|      Operations      | SINGLETONLIST | LIST::OF | ARRAYS::ASLIST | JAVA.UTIL.ARRAYLIST |
+----------------------+---------------+----------+----------------+---------------------+
|          add         |       ❌      |     ❌  |        ❌      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|        addAll        |       ❌      |     ❌  |        ❌      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|         clear        |       ❌      |     ❌  |        ❌      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|        remove        |       ❌      |     ❌  |        ❌      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|       removeAll      |       ❗️       |     ❌   |        ❗️       |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|       retainAll      |       ❗️       |     ❌  |        ❗️        |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|      replaceAll      |       ❌      |     ❌  |        ✔️       |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|          set         |       ❌      |     ❌  |        ✔️       |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|         sort         |       ✔️       |     ❌   |        ✔️      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
|  remove on iterator  |       ❌      |     ❌  |        ❌      |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+
| set on list-iterator |       ❌      |     ❌  |        ✔️       |          ✔️          |
+----------------------+---------------+----------+----------------+---------------------+

1. ✔️ significa que el método es compatible
2. ❌ significa que llamar a este método arrojará una UnsupportedOperationException
3. ❗️ significa que el método es compatible solo si los argumentos del método no causan una mutación, por ejemplo, Collections.singletonList ("foo"). RetenerAll ("foo") está bien, pero Collections.singletonList ("foo"). RetenerAll ("bar") ) arroja una UnsupportedOperationException

Más sobre colecciones :: singletonList Vs. Lista de