help scjp5.0 question1

[nikunj thakur]

class Alien {
String invade(short ships) { return "a few"; }
String invade(short... ships) { return "many"; }
}
class Defender {
public static void main(String [] args) {
System.out.println(new Alien().invade(7));
}
}

What is the result?

many

a few

Compilation fails.

The output is not predictable.

An exception is thrown at runtime.
the ans is c i understood but i didn't understand the explanation in the book
explain please

[kaarthick Ramamurthy]

Hi,

In class Alien there are two invade methods. First invade method can take only one short value and the next one takes array of short value.

  new Alien().invade(7)  

You have called the first invade method which takes only one short value.

Hope this clears your doubt.

[Abhijit Das]

dear ,Nikunj,

The answer is can not be complied.
the following statement
System.out.println(ob.invade(7));

needs explicit type cast because default numeric type is int. But arguments are in short type.

And , the function invade(short ships) will be called , because it have more preference than the var type arg. function.

Thanks
Abhijit

[Alejandro Galv�n]

Hi:

The compiler prefers to use the overloaded method that takes only one short value instead of the one which takes an array of shorts (we can say that it prefers easier ways, and is more easy to use a primitive than a var-args, and var-args came in the lastest versions of java, so the compiler says too that if one thing is older than other, it takes it) (wow, i think i wrote is so hard, if i'm complicating the stuff, just think in easier ways), most of times and questions like this will behave in the same way, the var-args is, normally tha last option for the compiler.

[Kelvin Chenhao Lim]

Hi Nikunj,

As Abhijit pointed out, the code won't compile as it currently stands without explicitly casting 7 to a short. But even if you did, the method invocation will be bound to the non-varargs version rather than the varargs version.

I'd summarized how the compiler tries to resolve these ambiguous calls in another recent thread. For convenience, I'll reproduce the key part here:

There's a well-defined rule for resolving these ambiguities. Basically, the compiler will go through three phases to match a method invocation to a method signature:

Phase 1: Match without boxing/unboxing and without var-args
Phase 2: Match with boxing/unboxing and without var-args
Phase 3: Match with boxing/unboxing and with var-args

If the compiler finds a match at an earlier phase, it will not proceed to subsequent phases. The basic rationale behind this rule is that this will preserve backward compatibility with older versions of Java. All method invocations from Java 1.4 and before will continue to be bound in the same way in Java 1.5.
[ November 17, 2007: Message edited by: Kelvin Lim ]

[Bert Bates]

Hi Nikunj,

Please continue to ask questions on this forum, and feel free to reproduce mock questions that you're studying! BUT, when you do reproduce a mock question, please indicate where you found it, i.e. the "source".

Thanks,

Bert