Arrays have been around from the beginning of Java, while varargs are a fairly recent addition. Thus a lot of older code still happily uses arrays.
Note also that calling a generic vararg method with an explicit array parameter may silently produce different behaviour than expected:
public <T> void foo(T... params) { ... }
int[] arr = {1, 2, 3};
foo(arr); // passes an int[][] array containing a single int[] element
Thus - apart from requiring a lot of effort for no clear benefit - it is not always desirable to replace legacy array parameters with varargs.
Not to mention the cases when you can't, because there is another parameter after the array in the method parameter list:
public void foo(String[] strings, String anotherParam) { ... }
Reordering the parameters may technically solve this, however it breaks client code.
Update: Effective Java 2nd. Edition, Item 42: Use varargs judiciously explains this in more details, giving also a concrete example: Arrays.asList()
was retrofitted in Java5 to have vararg parameters, which inadvertently broke a lot of existing code may cause surprises when using this (now obsolete) idiom to print an array:
System.out.println(Arrays.asList(myArray));
Update2: Double checked the source, and it says that the problem occurrs with arrays of primitive types, such as int[]
. Before varargs, code like this:
int[] digits = { 3, 1, 4, 1, 5, 9, 2, 6, 5, 4 };
System.out.println(Arrays.asList(digits));
would emit a compilation error, because only arrays of reference types could be converted to a List
. Since varargs, and retrofitting asList
, the code above compiles without warnings, and the unintended result is something like "[[I@3e25a5]"
.