File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes overloaded  var - args Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "overloaded  var - args " Watch "overloaded  var - args " New topic
Author

overloaded var - args

konkona
Greenhorn

Joined: Aug 09, 2007
Posts: 3
I am running this code

public class MyClass {

public static void main(String args[]){

Integer i= new Integer(2);
MyClass c= new MyClass();
c.method(i); // compile error
long l = 2l;
c.method(l); // this compiles
}

void method(long...x){
System.out.println("long");
}
void method(Integer...x){
System.out.println("Integer");
}
}

It looks like in the first case then I pass Integer It should call the second method but it gives compiler error that method(long[]) is ambiguous.
If I remove that line everything runs fine.
I cant understand why long and Integer are having conflicts.
Please enlighten me :-)
Vas Golla
Greenhorn

Joined: Aug 09, 2007
Posts: 8
Both the methods are same as far as varargs usage is concern. ( since both has only 1 agrs...
Chinni Bujji
Ranch Hand

Joined: Jan 31, 2007
Posts: 60
public class NewClass
{

public static void main(String args[]){

Integer i= new Integer(2);
NewClass c= new NewClass();
c.method(i); // compile error
long l = 2l;
c.method(l); // this compiles
}

void method(long x){
System.out.println("long");
}
void method(Integer x){
System.out.println("Integer");
}
}
Chinni Bujji
Ranch Hand

Joined: Jan 31, 2007
Posts: 60
public class NewClass
{

public static void main(String args[]){

Integer i= new Integer(2);
NewClass c= new NewClass();
c.method(i); // this compiles
long l = 2l;
c.method(l); // this compiles
}

void method(long x){
System.out.println("long");
}
void method(Integer x){
System.out.println("Integer");
}
}


this code works fine please check this no errors
Vas Golla
Greenhorn

Joined: Aug 09, 2007
Posts: 8
Check this and figure out...

public class MyClass {

public static void main(String args[]){

Integer i= new Integer(2);
//int i = 100;
MyClass c= new MyClass();
c.methodx(i);
long l = 2l;
c.methodx(l);
}

void methodx(long...x){
System.out.println("long");
}
//void methodx(int...x){
//System.out.println("Integer");
//}
}
konkona
Greenhorn

Joined: Aug 09, 2007
Posts: 3
public class MyClass {

public static void main(String args[]){

int a = 2;
label:
switch(a){
case 2: System.out.println("hello");
break label;
case 3: System.out.println("good bye");
}
Integer i= new Integer(2);
MyClass c= new MyClass();
c.method(i,i,i); // compile error
long l = 2l;
c.method(l); // this compiles
}

void method(long...x){
System.out.println("long");
}
void method(Integer...x){
System.out.println("Integer");
}
}
I changed the method call with multiple arguments c.method(i,i,i); but still it does not work.
I am confused why method(Integer...x) and method(long...x) has conflict but method(Integer) and method(long) does not.
Vas Golla
Greenhorn

Joined: Aug 09, 2007
Posts: 8
public class MyClass {

public static void main(String args[]){

Integer i= new Integer(2);
//==================NOTE THIS============
Long l= new Long(21);
//long l = 21;
//int i = 100;

MyClass c = new MyClass();

c.methodx(i);

c.methodx(l);
}

void methodx(Integer...y){
System.out.println("long");
}

void methodx(Long...x){
System.out.println("Integer");
}
}
Vas Golla
Greenhorn

Joined: Aug 09, 2007
Posts: 8
http://www.developer.com/java/other/article.php/3323661

"You might use varargs to allow adding one to many objects to a collection that you have defined by using a single add method call."

Thanks Konkana!!
even i came to know that only Objects can be varargs

in fact iam new too to java 5
konkona
Greenhorn

Joined: Aug 09, 2007
Posts: 3
VAS
Your example shows that when you changed method(long..x) to method(Long..x) it compiles. So does that mean there is no autoboxing in var-args?
But as far as i know thats not the case.
Vas Golla
Greenhorn

Joined: Aug 09, 2007
Posts: 8
Check this out for the diff... between them
http://java.sun.com/j2se/1.5.0/docs/guide/language/varargs.html
Fedry Kemilau
Ranch Hand

Joined: Aug 06, 2007
Posts: 44
Hi konkona,

Here what I think.

Integer will be implicitly casted to long primitive value. That is why, the compiler will tell us that the method is ambiguous.

If we try this code


This will compile, since Integer cannot be implicitly casted to short.

Correct me if I were wrong.
[ August 09, 2007: Message edited by: fedry kemilau ]

Solve this code:<br /> <br />10010101100001111011011000010100000111001011011111100011110101111100110100001
Manfred Klug
Ranch Hand

Joined: Jun 04, 2007
Posts: 377
Originally posted by konkona kk:
I am confused why method(Integer...x) and method(long...x) has conflict but method(Integer) and method(long) does not.
The search for a method is divided into three steps.

The first step searches for a method without consideration of boxing, unboxing or variable arguments. If you take this into account, it should be obvious why method(Integer) and method(long) don't conflict.

The third step searches for methods with variable arguments. But this time with consideration of boxing and unboxing. As result, the compiler could either widen the int to a long or box the int to an Integer. So the compiler has to decide which of the two methods is the most specific one. And in the case of method(Integer...x) and method(long...x), none of the two is more specific than the other one.

For a discussion about the most specific method, look here or search in the forum.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14117
    
  16

konkona kk and VAS: Welcome to JavaRanch.

Please check your private messages. You can see your private messages by clicking "My Profile" at the top right of the page. Thank you.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Burkhard Hassel
Ranch Hand

Joined: Aug 25, 2006
Posts: 1274
Howdy ranchers,

the posting of Manfred is correct but something should be added to it.

The original code from "konkona" is only a special case of something that is a known bug in the java language itself.

When I change the code in a way that does not contain autoboxing at all:

Changes are in bold.
So this has nothing to do with unboxing in the first place.
But when in the original code the unboxing happens, it will lead to the known old bug.

This bug is refered here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6199075




Yours,
Bu.


all events occur in real time
Kai Witte
Ranch Hand

Joined: Jul 17, 2004
Posts: 356
hello,

I don't think that the developers of the various reference implementations put as much thought into this as you just did, and the implementation of such issues (varargs combined with autoboxing) varies, especially between 1.5.0 and the following compiler implementations. This code for example compiles with 1.5.0, but not with 1.5.0_01:

(1.5.0 was the last one developed by Neal Gafter.) If you compiled it with 1.5.0 it would run fine with any following version and call the intuitively expected more specific method, though.

I would find it very unfair if such a thing were asked in any kind of test.

Kai


Kai Witte's business website Kai Witte's private homepage
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Burki]: The original code from "konkona" is only a special case of something that is a known bug in the java language itself.

I disagree - the bug in the report is indeed a bug, but the code in the first post of this thread is not a special case of that. When the two methods are method(long... x) and method(Integer... x), neither is considered more specific than the other, because long is not a subtype of Integer, and Integer is not a subtype of long. See here for more details. (And where does this code come from, since we now have several other topics with people asking nearly the same question?)

Kai: I would say they certainly could have, and perhaps should have, written the spec differently. Neal did his work before the JLS3 was completed; I assume this is something that was under discussion around that time. I recall that certain projects like, say, JTiger got caught by last-minute changes they made there, which is an unfortunate risk of developing for a new release. Anyway, I'm just saying that the compiler behavior seen here is consistent with the JLS as it was released. (Where "here" means in this thread, excluding the similar-but-different code in Bug 6199075.)


"I'm not back." - Bill Harding, Twister
Kai Witte
Ranch Hand

Joined: Jul 17, 2004
Posts: 356
hello Jim,

you are right, my TestCase2 above should not compile according to the JLS. Neal Gafter started the implementation based on a preliminary (and as far as I know unpublished) vararg spec. According to that spec the check for the more specific method used similar rules to the ones in the check for method applicability, taking boxing into account. The author of the official JLS wrote it differently: Simpler, but less intuitive, without taking boxing into account. The result is that the official 1.5.0 RI does not work in full compliance with the JLS, which was "fixed" in 1.5.0_01.

I do not think that the foo(int ...i) vs. foo(double...d) is a bug. JLS 15.12.2.5, "Choosing the Most Specific Method" is relevant here. The subsection specifically for varargs is simple in our case, because in our case n = 1 and k = 1. Insert that and the description becomes quite simple. Basically it sais that the vararg part of a method is not relevant for choosing the most specific method. So neither method is more specific, and certainly not strictly more specific, than the other one.

Kai
[ August 18, 2007: Message edited by: Kai Witte ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: overloaded var - args