Variable Arguments (Varargs)

Variable Arguments (Varargs) were introduced in Java 5 to allow a method to accept zero or more arguments of a specified type. Rather than forcing callers to instantiate and pass arrays explicitly, the compiler automatically wraps the arguments in a temporary array under the hood.

Syntax and Compiler rules

Java enforces two strict syntactic rules for varargs parameter declarations:

1. Last Parameter: The varargs parameter must be the last parameter in the method signature. E.g., void method(int a, String... names) is valid, but void method(String... names, int a) is invalid.
2. Single Varargs Parameter: A method can contain at most one varargs parameter.

Under the hood, the compiler translates Type... name to an array parameter Type[] name. When the method is invoked with comma-separated arguments, the compiler generates bytecode that allocates an array of the required size and populates it with the arguments before calling the method.

Overloading Resolution Precedence

Varargs has the lowest priority in method overloading resolution. When matching method calls, the compiler follows this search sequence:

• Exact Match: Matches the parameter types exactly without modifications.
• Widening: Widens primitives (e.g. promoting int to long).
• Autoboxing/Unboxing: Converts primitives to object wrappers or vice versa.
• Varargs: Evaluates varargs methods only if no other matches succeed.

Generic Heap Pollution and @SafeVarargs

Because varargs is implemented as an array, declaring a generic varargs parameter (e.g. <T> void print(T... elements)) requires the JVM to create a generic array: T[].

Since Java generics are erased at runtime, this array compiles to an Object[]. If the method body mutates this array with incompatible types or leaks the array reference to other parts of the program, it can cause a hidden ClassCastException at runtime—a condition known as Heap Pollution.

To suppress the compiler's safety warnings, apply the @SafeVarargs annotation. This annotation is a promise to the compiler that: 1. The method does not store or write invalid elements into the varargs array. 2. The method does not leak the array reference to the outside world. Note: @SafeVarargs can only be applied to final methods, static methods, or private methods (since Java 9), which cannot be overridden.

Common Pitfalls

• Ambiguous Overloading: Creating overloaded methods like method(int... a) and method(Integer... a), which causes compile-time ambiguity when called with literal integers.
• Declaring Varargs early in parameter lists: Placing varargs before other parameters, causing syntax compilation failures.
• Performance issues in tight loops: Calling varargs methods inside tight loops, causing constant temporary array allocations that increase garbage collection pressure.

Best Practices

• Use varargs primarily for utility methods (like logger outputs or print helpers) where it improves calling readability.
• Always annotate generic varargs methods with @SafeVarargs once you verify the method does not leak or mutate the array.
• Avoid overloading methods where one of the signatures relies on a varargs parameter to prevent compiler ambiguity.

Interview-Relevant Information