aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Widening, Boxing & Vararg and Overloading Confusion Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Widening, Boxing & Vararg and Overloading Confusion" Watch "Widening, Boxing & Vararg and Overloading Confusion" New topic
Author

Widening, Boxing & Vararg and Overloading Confusion

Yalvin Duha
Ranch Hand

Joined: Apr 07, 2012
Posts: 40

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

Joined: Apr 11, 2012
Posts: 21
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

Joined: Apr 07, 2012
Posts: 40

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
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

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

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Yalvin Duha
Ranch Hand

Joined: Apr 07, 2012
Posts: 40

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Widening, Boxing & Vararg and Overloading Confusion