views:

249

answers:

5

If I try to write a method like below

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

I get this error

The variable argument type Object of the method someStuff must be the last parameter.

I don't fully understand the requirement of variable argument type to be the last. Any inputs will be helpful.

+6  A: 

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.

Mark Byers
+1, life can't be more simpler :)
Ravi Gupta
+7  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 cant be safely put into args and there is no ambiguity over the variables.

linead
Theoretically, it would be technically possible. The technical problem only starts when you use 3 or more arguments and varargs isn't the first or the last of them.
BalusC
@Balus: There is still no ambiguity even when the varargs is in the middle, only a difficulty of implementation in the compiler, but in theory it's possible. The real problem comes when you have more than one vararg term. Then you have to have things like backtracking to resolve which is meant. It basically becomes as difficult to resolve as regexp matching.
Mark Byers
would make for a fun language feature though: pass-by-regexp. `void foo(^([0-9]*)(A|B.)(bar)?$)`
MSalters
+2  A: 

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).

Daff
Yes, sounds very logical
Ravi Gupta
@Daff, I think your example has nothing to do with varargs. Even if the method is: public void someStuff(Object args, String a) the compiler still has to decide whether to use : someStuff(Object, String) or someStuff(String, String). Or is it I miss something in your explanation ?
sateesh
Hm ok I didn't know if I explained it the best way and I don't claim that this is THE correct explanation. Basically it is mainly a compatibility thing since varargs have been added later in the java language and are treated like an array. So my guess is that they didn't want to change the lookup algorithms for choosing the right method to call which you don't have to, when you can make sure, that only the last parameter can be a vararg.
Daff
+4  A: 

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.

MSalters
Hmm..maybe this is what @S.Lott was referring to.
Ravi Gupta
It is, altough slightly simplified (hence the "conceptually at offset 0"). In practice you only have one stack which also holds register spills, return addresses, etc.
MSalters
It is. The reasoning for ... being last in Java is "because that's the rule." The reason for ... being last in C is an insane piece of C-compiler trivia. The "why" isn't helpful. The rule just is.
S.Lott
A: 

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.

Tendayi Mawushe