Because it's a lot harder to determine where the first vararg list ends and the second one stops, than just simply start the vararg list and only stop when you take all parameters.
Granted, in this example it could have been possible to have 2 sets of varargs, but the general rule would become more complex. Sun would need to add exceptions to the general rule for things like the following:
As you see, there would be much confusion, both for the compiler and the programmer. You could specify in the Java Language Specification that the two vararg lists should be 100% incompatible, but that's actually impossible*. Consider:
It seems that Serializable and List<?> are incompatible - but you can create your own class that makes them both compatible.
* Ok, impossible may be too harsh, but because of these problems there would be quite a few limitations. For instance:
- none of the vararg types can be an interface; with the exception of final classes, any class can be subclassed so it implements an interface
- none of the vararg types can be a super class of any of any of its adjacent vararg types (see the Integer / Number example)
The varargs rule would become so complex that programmers would get confused, and the compiler would need to be rewritten as well - it can't simply collect varargs until there are no more left, it needs to check each next vararg to see if it's part of the current varargs list or the next one.
So instead of two varargs lists, turn one (or both) into explicit arrays. That's what the compiler does with varargs anyway - it turns it into an array. For example:
When decompiled using JAD, I get this: