Varargs in Java — Variable Arguments and Heap Pollution
Fast recall
Quick revision
Core answer
Type... args) = syntactic sugar — compiler converts to array. Must be last parameter, at most one per method. Can pass 0+ args or an explicit array. Heap pollution with generics (T... args) — @SafeVarargs when provably safe. Null trap: method(null) passes as null array — args.length throws NPE. Avoid combining varargs with overloading — compiler resolution can produce surprises.Whether the candidate understands that varargs are syntactic sugar for arrays — the compiler creates the array at the call site — and can explain heap pollution when varargs combine with generics
Not knowing that varargs must be the last parameter. Passing an existing array to a varargs method and expecting it to be wrapped in another array — it isn't, the array IS the varargs. Confusing overload resolution ambiguity when multiple varargs methods match
Explain heap pollution — when a generic varargs parameter like T... is actually Object[] at runtime due to erasure, allowing type-unsafe elements. Know that @SafeVarargs suppresses the warning only when the method doesn't store into the array or expose it
Interview-ready guide
Interview answer
Varargs are syntactic sugar — the compiler converts print("a", "b", "c") to print(new String[]{"a", "b", "c"}) at the call site. The method receives a regular array with no special runtime treatment.
The basics
- Must be the last parameter; only one per method
- Zero arguments gives an empty array, not null —
args.lengthis safe, but check forargs == nullif you accept explicit nulls - Passing an existing array doesn't wrap it —
print(existingArray)passes the array itself as the varargs
Generic varargs and heap pollution
void addAll(T... items) addAll(Object[] items)via type erasure- If the method stores into or returns this array,
ClassCastExceptionfires at the caller, not inside the method — confusing because the crash happens far from the root cause @SafeVarargssuppresses the warning but is only safe when the method reads elements without writing to or leaking the array
Overloading trap
m(int... a)andm(int a, int... b)are ambiguous form(1)— compiler error, not a picked winner
I recommend keeping varargs methods simple — iterate the elements and never let the array escape the method, to avoid the heap pollution surprises.
Varargs in Java — Variable Arguments and Heap Pollution
Direct Answer
Varargs (Type... args) = syntactic sugar — compiler converts to array. Must be last parameter, at most one per method. Can pass 0+ args or an explicit array. Heap pollution with generics (T... args) — @SafeVarargs when provably safe. Null trap: method(null) passes as null array — args.length throws NPE. Avoid combining varargs with overloading — compiler resolution can produce surprises.
Common Mistakes & Pitfalls
Not knowing that varargs must be the last parameter. Passing an existing array to a varargs method and expecting it to be wrapped in another array — it isn't, the array IS the varargs. Confusing overload resolution ambiguity when multiple varargs methods match
Check your understanding
Answer these without looking back at the article.
- What does the compiler actually generate for a varargs method call?
- What is heap pollution in the context of generic varargs and what does @SafeVarargs guarantee?
- What happens if you pass null to a varargs method — is it an empty array or a null reference?
- Why must the varargs parameter always be in the last position?
- When should you prefer explicit overloads over a varargs method?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.