Java - Taille d'un tableau et length - Évitez les erreurs !

En Java, la taille d’un tableau se lit très simplement, mais une erreur de syntaxe suffit à bloquer le code ou à créer un bug discret. Le vrai sujet n’est pas seulement de récupérer un nombre: il faut aussi comprendre pourquoi un tableau a une taille fixe, comment éviter les indices hors limites et quand il vaut mieux passer à une collection. Je vais aller droit au but avec des exemples concrets, des pièges fréquents et la différence entre tableau, chaîne et liste.

La bonne manière d’obtenir la taille d’un tableau

Pour un tableau, la règle est simple: on utilise length, sans parenthèses. En Java, ce n’est pas une méthode mais un champ associé à l’objet tableau. La documentation Oracle rappelle d’ailleurs que la longueur est fixée lors de la création du tableau, puis lue ensuite directement.

int[] notes = {12, 15, 9, 18};

System.out.println(notes.length); // 4

Dans une boucle, ce réflexe évite les erreurs de borne. J’écris presque toujours la condition ainsi: i < notes.length, jamais i <= notes.length. Dès que tu gardes ce détail en tête, la plupart des accès hors limites disparaissent.

C’est aussi ce qui distingue un tableau d’un autre type de structure: sa taille est connue, simple à lire, mais pas destinée à évoluer librement. Cette rigidité explique pourquoi certaines erreurs reviennent souvent.

Pourquoi la taille d’un tableau reste fixe

Un tableau est créé avec une taille donnée, et cette taille ne change plus ensuite. Si tu écris new int[10], tu obtiens exactement dix cases, ni plus ni moins. Pour agrandir ou réduire un tableau, il faut créer un nouvel objet et recopier les valeurs utiles.

import java.util.Arrays;

int[] data = {3, 7, 11};
int[] plusGrand = Arrays.copyOf(data, 6);

System.out.println(plusGrand.length); // 6

Le point important, c’est que copyOf ne modifie pas l’original: il produit un nouveau tableau. Si tu agrandis un tableau d’entiers, les nouvelles cases sont remplies avec la valeur par défaut du type, donc 0 pour int, false pour boolean et null pour une référence. C’est une différence pratique, car elle conditionne la façon dont tu traites les données après la copie.

En pratique, si la structure doit changer très souvent, je ne m’obstine pas à forcer un tableau à faire le travail d’une collection. C’est là que les erreurs d’indices deviennent plus visibles.

Indices, bornes et erreurs qui reviennent souvent

En Java, le premier élément d’un tableau est à l’indice 0. Le dernier n’est donc pas length, mais length - 1. C’est le piège classique: si tu utilises directement la taille comme index, tu sors du tableau.

• for (int i = 0; i < notes.length; i++) parcourt tout le tableau sans dépasser la borne.
• for (int i = notes.length - 1; i >= 0; i--) parcourt le tableau à l’envers.
• for (int valeur : notes) est idéal si tu lis les éléments sans avoir besoin de l’indice.

Une fois ce réflexe acquis, le cas des tableaux à plusieurs dimensions devient beaucoup plus lisible.

Tableaux multidimensionnels et longueur de chaque ligne

Avec un tableau à deux dimensions, il faut distinguer la taille du conteneur principal et celle de chaque sous-tableau. matrix.length donne le nombre de lignes, tandis que matrix[i].length donne le nombre d’éléments de la ligne concernée.

int[][] grille = {
    {1, 2, 3},
    {4, 5},
    {6, 7, 8, 9}
};

System.out.println(grille.length);    // 3 lignes
System.out.println(grille[0].length); // 3 éléments
System.out.println(grille[1].length); // 2 éléments

Ce point surprend souvent les débutants, parce qu’en Java un tableau multidimensionnel est en réalité un tableau de tableaux. Les lignes peuvent donc avoir des tailles différentes. Si tu traites une matrice irrégulière, il faut toujours lire la longueur de la ligne courante au lieu de supposer que toutes les lignes ont la même dimension. Cette nuance devient essentielle dès que tu manipules des données issues d’un fichier, d’une API ou d’un calcul intermédiaire.

Et c’est aussi là qu’on voit la limite du tableau classique face à une collection plus souple.

Quand un tableau ne suffit plus

Si la structure doit grandir, rétrécir ou recevoir beaucoup d’insertions, un tableau n’est pas l’outil le plus souple. Dans ce cas, je bascule souvent vers ArrayList, parce que la notion de taille y est dynamique et qu’on lit le nombre d’éléments avec size(), pas avec length.

En pratique, je garde les tableaux pour les tailles connues à l’avance, les structures simples et les traitements proches du bas niveau. Dès que la donnée vit, change souvent ou dépend d’entrées utilisateur, la collection devient plus robuste. C’est moins élégant au sens théorique, mais nettement plus confortable à maintenir.

Cette distinction simple évite aussi de confondre les syntaxes, ce qui reste l’une des sources d’erreurs les plus fréquentes en Java.

Le réflexe qui évite les confusions au quotidien

Quand je relis du code Java, je vérifie toujours trois choses: est-ce bien un tableau, est-ce une chaîne ou une liste, et l’accès à la taille utilise-t-il la bonne syntaxe. Cette vérification prend quelques secondes, mais elle évite des erreurs très bêtes qui coûtent du temps au débogage.

• array.length pour un tableau.
• string.length() pour une chaîne.
• list.size() pour une collection.

Si tu retiens seulement cette distinction, tu couvres déjà l’essentiel. Pour le reste, la règle ne change pas: une taille fixe avec les tableaux, une taille évolutive avec les collections, et toujours des indices bornés par 0 et length - 1. C’est le genre de discipline qui rend un code Java plus clair, plus sûr et beaucoup plus simple à maintenir au quotidien.