It follows the C convention. The C convention in turn is based on CPU architectures which pass arguments on the stack. The first non-vararg arguments end up at a fixed offset in the stackframe. If you could put the vararg arguments first, the stack offset of the following arguments would depend on how many vararg parameters you would have passed. This would greatly complicate the amount of code needed to access them.

In your example, with String a first, it’s conceptually at offset 0 independent how the number of vararg arguments that follow. But with String a last, it could be at offset 0, 4, 8, 12 etc – you’d have to calculate args.size * 4 everytime you needed String a.

The variable argument has to be the last so the compiler can work out which argument is which.

For example, say you pass

“test”, “test”, “test”, “test”

into your function

public void someStuff(Object ... args, String a)

Java cannot work out if you want the args variable to contain 3 or 4 strings. It may be obvious to you at the time of writing but it’s ambiguous.

However, when it’s the other way around

public void someStuff(String a, Object ... args)

The Java compiler sees the first string, stick it into “a” and then knows that the remaining strings can be safely put into args and there is no ambiguity over the variables.

Because that would make the language unnecessarily complex. Imagine if you also allowed other syntaxes:

public void someStuff(String a, Object ... args, String b)
{
}

Or even:

public void someStuff(String a, Object ... args, int b, Object ... args2)
{
}

This second syntax means a string followed by any number of arguments of type Object, followed by an integer, followed by more objects. Sure you could design a language that could accept things like that, but what if you also wanted to specify that the args2 must contain at least one element, but args can be empty? Why can’t we do that too? You could design such a language.

It boils down to, how complicated do you want the rules to be? In this case they chose a simple option that fulfils the needs.

Well, a String is also an instance of Object, so if you are using varargs, your vararg array has to be the last parameter because the compiler can’t really decide what is args and what is your string a. Think of the method call as a tuple of method name and a list of objects which are your parameters. If you have two methods like so:

public void someStuff(Object ... args, String a )
public void someStuff(String a, String b)

The compiler couldn’t decide what method to choose for
someStuff("Hello", "Hello") .
If you put your String a as the first argument it can decide that someStuff(String, String) is more specific than someStuff(String, Object).

Given how a method with var args is used any other format could lead to ambiguities. Having the varargs last prevents possible ambiguities without requiring additional syntax to resolve the ambiguities which would lessen the benefit of the feature.

Consider the follow method declaration:

public void varargsAreCool(String surname, String firstname, 
                           String... nicknames) {
    // some cool varargs logic
}

When used like varargsAreCool("John", "Smith") it is obvious that John Smith has no nicknames. When used like this varargsAreCool("Andrew", "Jones", "The Drew", "Jonesy").

Now consider the following invalid method declaration:

public void varargsAreCool(String surname, String... nicknames,
                           String firstname) {
    // some cool varargs logic
}

When used like varargsAreCool("John", "Smith") is Smith John’s nickname or his surname? If it is his surname how do I indicate that he has no nicknames? To do this you would probably have to use the method like this varargsAreCool("John", new String[]{}, "Smith") which is clunky and somewhat defeats the purpose of the feature.

When used like this varargsAreCool("Andrew", "The Drew", "Jonesy", "Jones") are the The Drew, Jonesy and Jones all nicknames and the surname is missing? Again this ambiguity could be resolved but at the cost of clunky additional syntax.