This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes confusing var-arg constructors Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "confusing var-arg constructors" Watch "confusing var-arg constructors" New topic
Author

confusing var-arg constructors

Anastasia Sirotenko
Ranch Hand

Joined: Jul 20, 2009
Posts: 64
I have a question inspired by Devaka's ExamLab question:

The original question was:

And it went ok, we have no constructor here, so get 0 in output.

Then i tried to play with constructors:

if i have one of them constructors:

or

then the code compile just fine, but when both of them are in code - then compiler doesn't compile this if i try to instantiate the class object.


I am a bit confused with the behavior, though i understand that normally no one would want to use all those constructors together.

Can one explain me the rules that stand behind this behavior?

PS found in another code example that we cannot use primitive and wrapper var-arg methods together. I think that solved my question - we can actually have those var-arg methods in our code as long as we don't try to use them - in that case compiler gets confused with ambiguous choice. (if in the Devaka's example we try to ct.Centrist(1,1); - we'll get the same compiler error)


[SCJP 6.0]
Jason Irwin
Ranch Hand

Joined: Jun 09, 2009
Posts: 327
What definitely wont compile is This is because varags are (well, how I think of them) arrays created on the fly by the JVM. So these are ambiguous constructors.

Now...as to the instantiation in your example; its because of autoboxing I think.This gives you an int[] at run time. That could apply to int[]/int... or Integer[]/Integer...This shows exactly the same issue. I am not really sure if autoboxing was a dumb idea - or if I am too stupid to follow the logic behind it. I'll stop not before I start ranting and raving!


SCJP6
Anastasia Sirotenko
Ranch Hand

Joined: Jul 20, 2009
Posts: 64
Thank you for helping me to sort this out 8)
Abhijeet Pathak
Ranch Hand

Joined: Jul 05, 2009
Posts: 33
Yeah Jason you are right. int... and Integer... are same (from Java 5 onwards) due to autoboxing


I am the one who knows that I don't know anything.
Abhijeet
Himanshu Kansal
Ranch Hand

Joined: Jul 05, 2009
Posts: 257
For that matter char... and Integer... too can't go together. Or stated in a broader way, any types where "boxing followed by widening" is conflicting, cannot go together.

Regards


Experience and talent are independent of age
Anastasia Sirotenko
Ranch Hand

Joined: Jul 20, 2009
Posts: 64
Himanshu Kansal wrote:For that matter char... and Integer... too can't go together. Or stated in a broader way, any types where "boxing followed by widening" is conflicting, cannot go together.

Not exactly right - only the primitive and its corresponding wrapper type can not be used together in var-arg methods. Since literal value of integer parameter is int by default if you dont't cast it explicitly to byte, its absolutely not confusing for constructor which method to use:




But this code won't compile:
Himanshu Kansal
Ranch Hand

Joined: Jul 05, 2009
Posts: 257
Anastasia Sirotenko wrote:
Himanshu Kansal wrote:For that matter char... and Integer... too can't go together. Or stated in a broader way, any types where "boxing followed by widening" is conflicting, cannot go together.

Not exactly right - only the primitive and its corresponding wrapper type can not be used together in var-arg methods. Since literal value of integer parameter is int by default if you dont't cast it explicitly to byte, its absolutely not confusing for constructor which method to use:




But this code won't compile:


You are not using "empty" constructors. Using that, even byte... and Long... wont compile together. So what I said was exaclty right.

Regards
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: confusing var-arg constructors