Java 9 a introduit de nouvelles méthodes d'usine pour les listes List.of:

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

Quelle est la différence entre l'ancienne et la nouvelle option? Autrement dit, quelle est la différence entre ceci:

Arrays.asList(1, 2, 3);

et ça:

List.of(1, 2, 3);

Arrays.asListrenvoie une liste modifiable alors que la liste retournée par List.ofest immuable :

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.asListautorise les éléments nuls alors que List.ofne le fait pas:

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

contains se comporte différemment avec les valeurs nulles:

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.asListrenvoie une vue du tableau passé, de sorte que les modifications apportées au tableau seront également reflétées dans la liste. Car List.ofce n'est pas vrai:

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]

Les différences entre Arrays.asListetList.of

Voir les JavaDocs et cet exposé de Stuart Marks (ou des versions précédentes de celui-ci).

J'utiliserai ce qui suit pour les exemples de code:

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

Immuabilité structurelle (Ou: non modifiable)

Toute tentative de changement structurelList.of entraînera un UnsupportedOperationException. Cela inclut des opérations telles que l' ajout , la définition et la suppression . Vous pouvez cependant modifier le contenu des objets de la liste (si les objets ne sont pas immuables), de sorte que la liste ne soit pas «complètement immuable».

C'est le même sort pour les listes non modifiables créées avec Collections.unmodifiableList. Seule cette liste est une vue de la liste d'origine, elle peut donc changer si vous modifiez la liste d'origine.

Arrays.asListn'est pas complètement immuable, il n'a pas de restriction sur set.

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

De même, changer le tableau de sauvegarde (si vous le maintenez) changera la liste.

L'immuabilité structurelle s'accompagne de nombreux effets secondaires liés au codage défensif, à la concurrence et à la sécurité qui dépassent le cadre de cette réponse.

Nulle hostilité

List.ofet toute collection depuis Java 1.5 ne permet pas nullen tant qu'élément. Tenter de passer nullen tant qu'élément ou même une recherche entraînera un fichier NullPointerException.

Puisqu'il Arrays.asLists'agit d'une collection de 1.2 (le Framework de collections), il autorise nulls.

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

Formulaire sérialisé

Depuis List.ofson introduction dans Java 9 et les listes créées par cette méthode ont leur propre forme sérialisée (binaire), elles ne peuvent pas être désérialisées sur les versions antérieures de JDK (pas de compatibilité binaire ). Cependant, vous pouvez dé / sérialiser avec JSON, par exemple.

Identité

Arrays.asListappels internes new ArrayList, ce qui garantit l'inégalité de référence.

List.ofdépend de la mise en œuvre interne. Les instances renvoyées peuvent avoir une égalité de référence, mais comme cela n'est pas garanti, vous ne pouvez pas vous y fier.

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

Il convient de mentionner que les listes sont égales (via List.equals) si elles contiennent les mêmes éléments dans le même ordre, indépendamment de la façon dont elles ont été créées ou des opérations qu'elles prennent en charge.

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

Mise en œuvre (avertissement: les détails peuvent changer au fil des versions)

Si le nombre d'éléments dans la liste de List.ofest de 2 ou moins, les éléments sont stockés dans des champs d'une classe spécialisée (interne). Un exemple est la liste qui stocke 2 éléments (source partielle):

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

Sinon, ils sont stockés dans un tableau de la même manière que Arrays.asList.

Efficacité temporelle et spatiale

Les List.ofimplémentations basées sur le champ (taille <2) sont légèrement plus rapides sur certaines opérations. Par exemple, size()peut renvoyer une constante sans récupérer la longueur du tableau et contains(E e)ne nécessite pas de surcharge d'itération.

Construire une liste non modifiable via List.ofest également plus rapide. Comparez le constructeur ci-dessus avec 2 affectations de référence (et même celle pour un nombre arbitraire d'éléments) à

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

ce qui crée 2 listes plus d'autres frais généraux. En termes d'espace, vous enregistrez l' UnmodifiableListemballage plus quelques centimes. Au final, les économies en HashSetéquivalent sont plus convaincantes.

Temps de conclusion: à utiliser List.oflorsque vous voulez une liste qui ne change pas et Arrays.asListlorsque vous voulez une liste qui peut changer (comme indiqué ci-dessus).

Résumons les différences entre List.of et Arrays.asList

1. List.ofpeut être mieux utilisé lorsque l'ensemble de données est inférieur et inchangé, alors qu'il Arrays.asListpeut être utilisé au mieux dans le cas d'un ensemble de données volumineux et dynamique.

2. List.ofprend très moins d'espace supplémentaire car il a une implémentation basée sur le terrain et consomme moins d'espace de tas, à la fois en termes de surcharge fixe et sur une base par élément. tandis que Arrays.asListprennent plus d'espace de surcharge car lors de l'initialisation, il crée plus d'objets dans le tas.

3. La collection retournée par List.ofest immuable et donc sécurisée pour les threads tandis que la collection retournée par Arrays.asListest mutable et non thread-safe. (Les instances de collection immuables consomment généralement beaucoup moins de mémoire que leurs homologues mutables.)

4. List.ofne permet pas null éléments tout Arrays.asListpermet nuls éléments.

En dehors des réponses ci-dessus, il existe certaines opérations sur lesquelles les deux List::ofet Arrays::asListdiffèrent:

+----------------------+---------------+----------+----------------+---------------------+
|      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. ✔️ signifie que la méthode est prise en charge
2. ❌ signifie que l'appel de cette méthode lèvera une exception UnsupportedOperationException
3. ❗️ signifie que la méthode n'est prise en charge que si les arguments de la méthode ne provoquent pas de mutation, par exemple Collections.singletonList ("foo"). ) lève une exception UnsupportedOperationException

En savoir plus sur les collections :: singletonList Vs. Liste de