• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

overloaded var - args

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 :-)
 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Both the methods are same as far as varargs usage is concern. ( since both has only 1 agrs...
 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Check this out for the diff... between them
http://java.sun.com/j2se/1.5.0/docs/guide/language/varargs.html
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1274
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[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.)
 
Kai Witte
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
reply
    Bookmark Topic Watch Topic
  • New Topic