• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Widening, Boxing & Vararg and Overloading Confusion

 
Yalvin Duha
Ranch Hand
Posts: 41
Eclipse IDE Java Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is one of those topics that I just cannot figure out the order which rules are applied in certain overloading scenarios.

I know that in isolation, for instance, 1) a primitive widening beats boxing, boxing beats vararg, and reflexively primitive widening beats vararg or 2) boxing/unboxing then widening is allowed, while 3) widening then boxing is not. Or 4) widening among wrapper classes are not permitted and 5) certain combination of widening/vararg in conjunction with boxing/vararg result in both overloaded methods being matched.

What I don't understand, in what order these rules are applied. For instance,

doSomething(Integer...) vs. doSomething(int...) with doSomething(1000) would choose doSomething(int...)

But, if we add another overloaded method:

doSomething(Integer...) vs. doSomething(int...) vs. doSomething(Object) with doSomething(1000) would choose doSomething(Object)

Or,

doSomething(Integer...) vs. doSomething(long...) vs. doSomething(Object) with doSomething(1000) would choose doSomething(Object)

while if the first two methods, Integer... and long..., are used in isolation, ambiguity arises.

I feel like, I'm not understanding the mechanism in which this cacophony of boxing, unboxing, and widening unfolds. The Java Language Specification is convoluted, and I can't make sense of it. Reading some the old posts also hasn't helped me fully understand this topic.

Can somebody shed light on it? Thanks.
 
Vineet Kumar Garg
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Make some small small programs while adding one overloaded method each time and see what happens.

Looks like I also need to do this exercise once more.
 
Yalvin Duha
Ranch Hand
Posts: 41
Eclipse IDE Java Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've already done that, but there are just way too many permutations to go through.

In either case, what's the point of mindlessly memorizing certain outcomes when you need to understand the concept/topic?
 
Henry Wong
author
Marshal
Pie
Posts: 21221
81
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yalvin Duha wrote:I've already done that, but there are just way too many permutations to go through.

In either case, what's the point of mindlessly memorizing certain outcomes when you need to understand the concept/topic?



There is actually a topic going on that discuss this in detail....

http://www.coderanch.com/t/417622/java-programmer-SCJP/certification/Golden-Rules-widening-boxing-varargs


Having said that .... I kinda disagree with the topic. Why? Well, boxing and widening are specified in the "method conversion" section of the Java Language Specification. Overloading (along with a mention of varargs) are mentioned near the discussion of the "most specific" rule. And quite frankly, IMO, the two sections are not completely clear on how everything works together.

The topic tries to figure out rules based on what behavior is seen, and not based on what the JLS says, and quite frankly, when stuff is up for interpretation, it may change from release to release, and version to version.

Henry
 
Yalvin Duha
Ranch Hand
Posts: 41
Eclipse IDE Java Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Henry.

I had read a few posts similar to that thread entry, nonetheless, they don't discuss at what point "method conversion" rules are kicked in and at what juncture "most specific" rules are applied (http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.2.1). And that's exactly what I was referring to; a very undeterministic methodology to confidently state that an invocation calls this particular overloaded method.

Does boxing/widening always precede vararg of supertype, i.e. doSomething(Object) wins over doSomething(long...) when doSomething(20) is called?

And if we have doSomething(new Integer(20)), and overloaded methods of doSomething(Long) and doSomething(long...), I understand why the former is discarded (widening and boxing is not allowed), but why does doSomething(long...) is called? Does the procedure, first unbox new Integer(20), then widens to select doSomething(long...)?

But if that's the case, when we add doSomething(Object) to the mix [of doSomething(Long) and doSomething(long...)], the same call (doSomething(new Integer(20))) result in doSomething(Object) to be called! So, is my previous assumption of "unboxing then widening" inaccurate?

Henry Wong wrote:
The topic tries to figure out rules based on what behavior is seen, and not based on what the JLS says, and quite frankly, when stuff is up for interpretation, it may change from release to release, and version to version.


Argh! That's what I was afraid of too.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic