Java Varargs: Methoden, die beliebig viele Argumente entgegennehmen

Eine Methode, beliebig viele Argumente

Manchmal weißt du im Voraus nicht, wie viele Argumente eine Methode braucht. Im einen Moment willst du max(3, 9), im nächsten max(1, 7, 4, 2, 8). Ohne Varargs müsstest du für jede Anzahl eine Überladung schreiben oder den Aufrufer zwingen, ein Array zu bauen. Varargs - kurz für variable Argumente - lassen eine einzelne Methode null, ein oder viele Werte desselben Typs annehmen.

Du deklarierst sie, indem du drei Punkte (...) hinter den Parametertyp setzt:

public class Main {
    static int sum(int... numbers) {
        int total = 0;
        for (int n : numbers) {   // numbers ist einfach ein 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 - null Argumente sind erlaubt
        System.out.println(sum(4, 8, 15, 16));   // 43
    }
}

Der Aufrufer übergibt lose Werte; innerhalb der Methode ist numbers ein echtes Array. Das ist die ganze Idee: Der Compiler bündelt die Argumente für dich in einem Array.

Varargs sind einfach ein Array

Zur Laufzeit gibt es keine Magie. Ein als int... numbers deklarierter Parameter ist genau ein int[], sobald du in der Methode bist. Du kannst seine length abfragen, darauf zugreifen und es wie jedes andere Array durchlaufen.

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

Da es wirklich ein Array ist, kannst du einer Varargs-Methode auch ein Array übergeben, das du bereits hast - sie akzeptiert beide Formen:

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));        // ein vorhandenes Array übergeben
        System.out.println(sum(1, 2, 3, 4));  // oder lose Werte
    }
}

Die Regeln: zuletzt und nur einer

Zwei Regeln halten Varargs eindeutig, und der Compiler erzwingt beide:

1. Der Varargs-Parameter muss der letzte sein. Normale Parameter kommen zuerst, dann saugt der ...-Parameter alles Übrige auf.
2. Eine Methode darf höchstens einen Varargs-Parameter haben. Bei zweien wäre es unmöglich zu erkennen, wo der eine endet und der nächste beginnt.

public class Main {
    // OK: normaler Parameter zuerst, Varargs zuletzt
    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");   // der Varargs-Teil darf leer sein
    }
}

Das kompiliert. Aber die Varargs zuerst zu setzen - static void log(Object... values, String level) - ist ein Kompilierfehler: varargs parameter must be the last. Der Pflichtparameter level steht immer vor dem ....

Wo du Varargs bereits benutzt

Du rufst die ganze Zeit schon Varargs-Methoden auf. System.out.printf und String.format sind die klassischen Beispiele - ihr zweiter Parameter ist 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(...) und viele APIs im Builder-Stil sind ebenfalls Varargs. Deshalb kannst du ihnen beliebig viele Elemente übergeben, ohne selbst etwas in ein Array zu verpacken.

Varargs und Überladung

Varargs und Überladung wirken auf eine überraschende Weise zusammen. Wenn eine normale Überladung und eine Varargs-Überladung beide zu einem Aufruf passen könnten, bevorzugt Java die speziellere - die Methode mit fester Argumentanzahl gewinnt:

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 (spezieller)
        System.out.println(pick(1, 2, 3));   // varargs version
        System.out.println(pick());          // varargs version
    }
}

pick(1, 2) passt zu beiden, aber Java wählt die Überladung ohne Varargs, weil sie die genauere Passung ist. Die Varargs-Methode läuft nur, wenn keine Überladung mit fester Argumentanzahl passt. Das ist meist genau das, was du willst, bedeutet aber, dass das Hinzufügen einer Varargs-Überladung stillschweigend ändern kann, zu welcher Methode ein Aufruf aufgelöst wird.

Achte auf leere und null-Aufrufe

Zwei Stolperfallen erwischen viele. Erstens: Eine Varargs-Methode ohne Argumente aufzurufen, übergibt der Methode ein leeres Array, nicht null - also ist numbers.length gleich 0 und die Schleife tut nichts. Für den Fall ohne Argumente brauchst du keine null-Prüfung:

public class Main {
    static int count(Object... items) {
        return items.length;   // 0 bei count(), nie eine NPE
    }

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

Zweitens: Ein wörtliches null zu übergeben ist mehrdeutig und gefährlich: Java kann count(null) als „das gesamte Varargs-Array ist null" statt als „ein null-Element" deuten, was dann eine NullPointerException wirft, wenn du seine length liest. Wenn du wirklich ein einzelnes null-Element meinst, sei explizit mit count((Object) null).

Als Nächstes: Klassen

Varargs runden ab, was du mit Methodenparametern tun kannst - flexible Argumentlisten zusätzlich zur Überladung. Bisher lebten die Methoden lose in einer Klasse mit static. Als Nächstes wirst du sehen, wie Klassen wirklich funktionieren: Daten (Felder) und Verhalten (Methoden) in eigenen Typen zu bündeln, was das Herzstück der objektorientierten Programmierung in Java ist.