• Post Reply Bookmark Topic Watch Topic
  • New Topic

Method is ambigous, method overloading with var-args widening and var-args boxing  RSS feed

 
Ernesto Hilvano
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi i would like to know why im getting ambigous error on the code on line "new Main().gos(1);"


Is it an IDE Issue?

Because based on kathy Sierra scjp6 reviewer page 306 last item under Advanced Overloading, " You Can Combine var-args with either widening and boxing".

While on the stackoverflow http://stackoverflow.com/questions/12879910/varargs-in-method-overloading-in-java
answer of Rohit Jain item number 7 he said "You cannot combine var-args, with either widening or boxing"

I am now confused please help.
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Go through the Java Language Specification with ctrl‑F‑overloading and look at the links. In one of them, you find the method signature has to be determined. You cannot distinguish those methods simply by counting parameters, so you go to the second stage. That doesn't work either, so you go to their third stage. That bit is really easy to read (‍) isn't it?

You can either change the 1 to a 1‑element array, or you can change it to an Integer and try to put it into an array. I hope by this time you are confused about which to choose, and so is the compiler. Since Java® is supposed to be an imperative language, it must be deterministic at this stage. You now have two possible paths of execution. The compiler also get confused about which to choose (it has been programmed to be confused) and the example is shown as an example of something which won't compile.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:Go through the Java Language Specification with ctrl‑F‑overloading and look at the links. In one of them, you find the method signature has to be determined. You cannot distinguish those methods simply by counting parameters, so you go to the second stage. That doesn't work either, so you go to their third stage. That bit is really easy to read (‍) isn't it?

To complete this: after stage three, you have two possible method invocations. So you proceed to JLS-15.12.2.5: Choosing The Most Specific Method, to see if there's a way to say that one invocation is more specific than another. Unfortunately, there isn't, because Integer is not a subtype of int, and int is not a subtype of Integer. That is why you get the compile error.

(For non-vararg methods, this would have been resolved by phase 1, ignoring boxing/unboxing, and the problem never would have gotten this far.)

Interestingly, the current version of the Java 8 JDK does allow this code to compile and run, choosing the (int...) version over the (Integer...) version. I would say this is a bug, in the sense that it does not follow the spec. Except it's a new Java version, and of course they're putting in many other things that change the JLS. So maybe they're planing on changing this part of the spec, and officially allowing (int...) to be more specific than (Integer...). We'll see.

I would say the preferred solution in all this is to not have both (int...) and (Integer...) versions as overloads. Choose the one you prefer, and delete the other. Or at least change it to a non-vararg version, e.g. change (Integer...) to (Integer[]). That would allow someone to explicitly pass in an array of Integer, but all other invocations would be handled by the (int...) version.
 
Ernesto Hilvano
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks for the reply, anyways, im planning to take the ocjp 6 exam that's why i want to know what method will be invoked


regards
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ernesto Hilvano wrote:thanks for the reply, anyways, im planning to take the ocjp 6 exam that's why i want to know what method will be invoked

6? That's a bit old.

It's possibly worth mentioning that the JLS was revised for version 7, but I have no idea how much - if anything - was changed. So if indeed this is a v6 exam, you might want to get your hands on a copy of the JLS for version 6.

Winston
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're welcome I presume you have realised the answer is neither method because it will fail to compile.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!