Comment convertir une List en tableau en Java

Une List et un tableau contiennent les mêmes éléments mais exposent des API différentes : une List se redimensionne et dispose de méthodes riches, tandis qu'un tableau a une longueur fixe et est ce que de nombreuses API anciennes ou bas niveau attendent. La conversion de l'un vers l'autre est une opération en une ligne en Java moderne — le seul vrai choix est quelle forme est la plus lisible et si vous avez besoin d'un tableau d'objets ou d'un tableau primitif. Cette page couvre la surcharge toArray typée, la référence de constructeur de Java 11+, la voie stream pour les tableaux primitifs, et les pièges du toArray() sans argument.

La méthode idiomatique : toArray avec un tableau typé

List.toArray(T[]) retourne un tableau fortement typé. Passez un tableau de longueur zéro du type d'élément et laissez le JDK dimensionner le résultat pour vous :

List<String> names = List.of("Ann", "Bob", "Cy");
String[] arr = names.toArray(new String[0]);

L'argument new String[0] transporte le type (String[]), pas un tampon pré-dimensionné. Sur les JVM modernes, la forme du tableau vide est recommandée — elle est aussi rapide qu'un tableau parfaitement dimensionné et évite le bogue où un tableau trop petit est réalloué et où un tableau trop grand laisse des null en fin de tableau. Utilisez cette méthode chaque fois que vous avez besoin d'un tableau de type Object comme String[], Integer[], ou votre propre classe.

La forme Java 11+ : une référence de constructeur de tableau

Depuis Java 11, vous pouvez passer une référence de constructeur de tableau à la place d'un tableau vide littéral. Cela dit exactement ce que cela signifie — « créez-moi un String[] » :

String[] arr = names.toArray(String[]::new);

Cela compile vers la même chose que new String[0] mais se lit plus clairement. Notez que le toArray() sans argument est un piège : il retourne toujours Object[], jamais String[], donc caster son résultat en String[] lève une ClassCastException à l'exécution.

Les tableaux primitifs passent par un stream

toArray ne peut produire que des tableaux d'objets. Une List<Integer> ne peut pas devenir directement un int[] — l'autoboxing ne s'étend pas aux tableaux. Utilisez un stream pour déboxer chaque élément :

List<Integer> nums = List.of(10, 20, 30);
int[] prim = nums.stream().mapToInt(Integer::intValue).toArray();

Le même pattern vous donne long[] (mapToLong) et double[] (mapToDouble). Il n'existe pas de raccourci JDK pour les tableaux primitifs, donc le stream est la voie idiomatique.

Un exemple pratique

Ce programme exécute chaque approche côte à côte, affiche le type d'exécution que le toArray sans argument retourne réellement, et prouve que le tableau résultant est une copie indépendante — le modifier ne touche pas la liste d'origine.

Ce qu'il faut retenir de l'exécution :

• toArray(new String[0]) et toArray(String[]::new) affichent tous les deux [Ann, Bob, Cy] — ce sont deux orthographes de la même conversion typée, et vous pouvez utiliser celle qui se lit le mieux dans votre base de code.
• Le toArray() sans argument rapporte son type d'exécution comme Object[], pas String[] — preuve concrète qu'il efface le type d'élément et pourquoi vous devriez éviter de caster son résultat.
• La List<Integer> ne devient un vrai int[] qu'après mapToInt ; le [10, 20, 30] affiché est un tableau primitif, pas un Integer[], donc aucun boxing ne subsiste.
• Arrays.stream(prim).sum() affiche 60, confirmant que le résultat est un tableau primitif utilisable que vous pouvez alimenter directement dans des opérations de stream numériques.
• Après a1[0] = "ZZ", le tableau affiche [ZZ, Bob, Cy] tandis que la liste affiche toujours [Ann, Bob, Cy] — toArray retourne une copie indépendante, donc les modifications du tableau ne se répercutent jamais dans la liste source.

Pratique