Varargs en Java : des méthodes qui acceptent un nombre quelconque d'arguments

Une méthode, un nombre quelconque d'arguments

Parfois vous ne savez pas à l'avance combien d'arguments une méthode va recevoir. Vous voulez max(3, 9) à un instant, puis max(1, 7, 4, 2, 8) juste après. Sans les varargs, il faudrait écrire une surcharge pour chaque nombre d'arguments ou forcer l'appelant à construire un tableau. Les varargs - abréviation d'arguments variables - permettent à une seule méthode d'accepter zéro, une ou plusieurs valeurs du même type.

On les déclare en plaçant trois points (...) après le type du paramètre :

public class Main {
    static int sum(int... numbers) {
        int total = 0;
        for (int n : numbers) {   // numbers est juste un int[]
            total += n;
        }
        return total;
    }

    public static void main(String[] args) {
        System.out.println(sum(1, 2, 3));        // 6
        System.out.println(sum(10, 20));         // 30
        System.out.println(sum());               // 0 - zéro argument est autorisé
        System.out.println(sum(4, 8, 15, 16));   // 43
    }
}

L'appelant passe des valeurs éparses ; à l'intérieur de la méthode numbers est un véritable tableau. C'est toute l'idée : le compilateur regroupe les arguments dans un tableau à votre place.

Les varargs ne sont qu'un tableau

Il n'y a pas de magie à l'exécution. Un paramètre déclaré int... numbers est exactement un int[] une fois que vous êtes dans la méthode. Vous pouvez interroger sa length, l'indexer et le parcourir comme n'importe quel autre tableau.

public class Main {
    static String join(String separator, String... parts) {
        if (parts.length == 0) {
            return "";
        }
        StringBuilder sb = new StringBuilder(parts[0]);
        for (int i = 1; i < parts.length; i++) {
            sb.append(separator).append(parts[i]);
        }
        return sb.toString();
    }

    public static void main(String[] args) {
        System.out.println(join("-", "2026", "06", "04"));  // 2026-06-04
        System.out.println(join(", ", "alone"));            // alone
    }
}

Comme il s'agit véritablement d'un tableau, vous pouvez aussi confier à une méthode varargs un tableau que vous possédez déjà - elle accepte les deux formes :

public class Main {
    static int sum(int... numbers) {
        int total = 0;
        for (int n : numbers) total += n;
        return total;
    }

    public static void main(String[] args) {
        int[] data = {5, 10, 15};
        System.out.println(sum(data));        // passe un tableau existant
        System.out.println(sum(1, 2, 3, 4));  // ou des valeurs éparses
    }
}

Les règles : en dernier et un seul

Deux règles évitent toute ambiguïté avec les varargs, et le compilateur les fait respecter toutes les deux :

1. Le paramètre varargs doit être en dernier. Les paramètres ordinaires viennent d'abord, puis le paramètre ... absorbe tout ce qui reste.
2. Une méthode peut avoir au plus un paramètre varargs. Deux rendraient impossible de savoir où l'un se termine et où le suivant commence.

public class Main {
    // OK : paramètre ordinaire d'abord, varargs en dernier
    static void log(String level, Object... values) {
        System.out.print("[" + level + "] ");
        for (Object v : values) {
            System.out.print(v + " ");
        }
        System.out.println();
    }

    public static void main(String[] args) {
        log("INFO", "user", 42, true);
        log("WARN");   // la partie varargs peut être vide
    }
}

Ceci compile. Mais placer les varargs en premier - static void log(Object... values, String level) - est une erreur de compilation : varargs parameter must be the last. Le paramètre obligatoire level précède toujours le ....

Là où vous utilisez déjà les varargs

Vous appelez des méthodes varargs depuis le début. System.out.printf et String.format en sont les exemples classiques : leur second paramètre est Object... args :

public class Main {
    public static void main(String[] args) {
        System.out.printf("%s scored %d points (%.1f%%)%n", "Ada", 95, 95.0);

        String row = String.format("%-8s | %5d", "banana", 30);
        System.out.println(row);
    }
}

List.of(...), Arrays.asList(...) et de nombreuses API de style builder sont aussi des varargs. C'est pourquoi vous pouvez leur passer un nombre quelconque d'éléments sans rien envelopper vous-même dans un tableau.

Varargs et surcharge

Les varargs et la surcharge interagissent d'une manière surprenante. Lorsqu'une surcharge ordinaire et une surcharge varargs pourraient toutes deux correspondre à un appel, Java préfère la plus spécifique : la méthode à arité fixe l'emporte :

public class Main {
    static String pick(int a, int b) {
        return "two-arg version";
    }

    static String pick(int... nums) {
        return "varargs version";
    }

    public static void main(String[] args) {
        System.out.println(pick(1, 2));      // two-arg version (plus spécifique)
        System.out.println(pick(1, 2, 3));   // varargs version
        System.out.println(pick());          // varargs version
    }
}

pick(1, 2) correspond aux deux, mais Java choisit la surcharge sans varargs car elle est la plus proche. La méthode varargs ne s'exécute que lorsqu'aucune surcharge à arité fixe ne correspond. C'est généralement ce que vous voulez, mais cela signifie qu'ajouter une surcharge varargs peut changer en silence la méthode vers laquelle un appel se résout.

Attention aux appels vides et à null

Deux pièges piègent les gens. Premièrement : appeler une méthode varargs sans argument remet à la méthode un tableau vide, et non null - donc numbers.length vaut 0 et la boucle ne fait rien. Vous n'avez pas besoin d'une vérification de null pour le cas sans argument :

public class Main {
    static int count(Object... items) {
        return items.length;   // 0 pour count(), jamais de NPE
    }

    public static void main(String[] args) {
        System.out.println(count());            // 0
        System.out.println(count("a", "b"));    // 2
    }
}

Deuxièmement : passer un null littéral est ambigu et dangereux : Java peut interpréter count(null) comme « tout le tableau varargs est null » plutôt que « un élément null », ce qui lève ensuite une NullPointerException quand vous lisez sa length. Si vous voulez réellement dire un unique élément null, soyez explicite avec count((Object) null).

Ensuite : les classes

Les varargs complètent ce que vous pouvez faire avec les paramètres de méthode - des listes d'arguments souples par-dessus la surcharge. Jusqu'ici, les méthodes ont vécu en vrac dans une classe avec static. Vous allez maintenant voir comment les classes fonctionnent réellement : regrouper des données (champs) et un comportement (méthodes) dans vos propres types, ce qui est le cœur de la programmation orientée objet en Java.