Problem with ints and doubles

[hszforu]

This is my code:

//VariableArguments3.java

public class VariableArguments3
{
  static void test(String s,int ...v)
  {
    System.out.println("length:"+v.length+" String:" +s);

    for(int x:v)
            System.out.println("x="+x);
  }

  static void test(String s,double ...d)
  {
    System.out.println("length:"+d.length+" String:" +s);



    for(double x:d)
        System.out.println("x="+x);
  }


}

and

//VariableArguments3.java
public class VariableArguments3Test
{
    public static void main(String args[])
    {
        VariableArguments3.test("harshal",33,43,34,23,24);
        VariableArguments3.test("hosha",43,442);
        VariableArguments3.test("hosha",67.7,7.53,73.23);
    }
}

i am getting following error:

VariableArguments3Test.java:5: reference to test is ambiguous, both method test(
java.lang.String,int...) in VariableArguments3 and method test(java.lang.String,
double...) in VariableArguments3 match
                VariableArguments3.test("harshal",33,43,34,23,24);
                                  ^
VariableArguments3Test.java:6: reference to test is ambiguous, both method test(
java.lang.String,int...) in VariableArguments3 and method test(java.lang.String,
double...) in VariableArguments3 match
                VariableArguments3.test("hosha",43,442);
                                  ^

Now i want to ask that why the VariableArguments3.test("harshal",33,43,34,23,24); and VariableArguments3.test("hosha",43,442); does not transfer the control to static void test(String s,int ...v) in the first file.

Why does it treat static void test(String s,int ...v) and static void test(String s,double ...d) as equal.
Why are the integers passed are treated as equal to double?Shouldn't the integer implicitly convert to double only when method for interger is not specified?

[JamesCherrill]

What version of Java are you running? I tried...

   public void x(String s, int... i) {System.out.println("i");}
   public void x(String s, double... d) {System.out.println("d");}
   public void run() {
      x("abc", 1,2);
      x("abc", 1.0,2.0);
   } 

... and that works exactly as you would expect - Java 1.7 Windows 64.

[hszforu]

i am using :
java version "1.6.0_33"
Java(TM) SE Runtime Environment (build 1.6.0_33-b03)
Java HotSpot(TM) Client VM (build 20.8-b03, mixed mode, sharing)
Windows 32 bits

[JamesCherrill]

Just to be sure, so it's just like yours, I tried

class Test {
   public static void x(String s, int... i) {System.out.println("i "+i[0]);}
   public static void x(String s, double... d) {System.out.println("d "+d[0]);}
}
...
public class Demo {

   public static void main(String[] args) {
      Test.x("abc", 1,2);
      Test.x("abc", 1.0,2.0);
   }
   ...

... and still it compiles and executes exactly as expected.
Can you try that exact code on your machine and see what result you get?

[hszforu]

when i execute your code i am getting this error:

Demo.java:5: reached end of file while parsing
   }→
    ^
1 error

[JamesCherrill]

Yes, obviously that wasn't a complete file (hence the ...'s between the classes and at the end). It just a bit of code that you can insert into an existing file to test it

[hszforu]

ok i will do it now.

[JamesCherrill]

Anybody else out there watching? Can anyone else replicate this?

[hszforu]

ok, the previous error occured because i didn't put } in the end.
Now i corrected it and i am getting the same error that i got first time.

Demo.java:3: reference to x is ambiguous, both method x(java.lang.String,int...)
 in Test and method x(java.lang.String,double...) in Test match
      Test.x("abc", 1,2);
          ^
1 error

[JamesCherrill]

Well now, this is very interesting. Culd this be a difference between 1.6 and 1.7?

[hszforu]

may be this could be the difference(but this should be executed using 1.6 also), but let's wait till some other member try to execute this using java 1.6

[DavidKroukamp]

public class JavaApplication186 {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        Test.x("abc", 1, 2);
        Test.x("abc", 1.0, 2.0);
    }
}

class Test {

    public static void x(String s, int... i) {
        System.out.println("i " + i[0]);
    }

    public static void x(String s, double... d) {
        System.out.println("d " + d[0]);
    }
}

Hmm I got this exact code to compile under JDK 7 and JDK6?

[hszforu]

Then what's the problem on my side?
How did you checked on both the versions?Can we keep both version installed on the same pc?

[JamesCherrill]

Thank you David. So what could it be about hszforu's configuration that's different?

[DavidKroukamp]

How did you checked on both the versions?Can we keep both version installed on the same pc?

I have both JDK's (yes you can) so just let my Netbeans compile under the libraries of each. I did your code too and all fine, I even went to JDK 5 (using netbeans project properties) but no error.

Not sure whats wrong.

Thank you David.

Pleasure

[DavidKroukamp]

reference to test is ambiguous

found an interesting article: http://www.coderanch.com/t/326225/java/java/Ambiguous-Reference-method especially this:

The problem here is that, when a value is passed to a mathod, it may be automatically converted to a wider data type For example, this is perfectly legal:

public class Test  
{  
    public void doIt(int a) {...}  

    public static void main(String[] args)  
    {  
        Test t = new Test();  
        byte b = 1;  
        t.doIt(b);  
    }  
}  

This is valid because a byte can be safely converted to an int. Therefore, an implicit cast takes place prior to invocation of the doIt method. You don't actually send a byte to doIt, you send an int to doIt. That int was created by implicitly widening the original byte value.

In your case, you have three integer literals. In Java, a numeric literal is considered an int. Therefore, you're trying to pass 3 ints to a method. The compiler then looks for any methods by that name that can take 3 ints. There is no such method, but there are these other two that can take combinations of ints and longs. Well, an int can be converted to a long, so these methods are applicable.

so as we can see the compiler doesnt know which to choose in the OPs code an int can be impliclity converted to a double, though I'm not sure why it won't replicate this on other PC's with same version, maybe its an IDE bug?

[JamesCherrill]

http://bugs.sun.com/view_bug.do?bug_id=6199075
It's a Java compiler bug. Fixed in Java 7.

[hszforu]

Ok thanks , but if it's a bug, then how DavidKroukamp successfully executed it under 1.6.

[DavidKroukamp]

I guess my netbeans complied using jdk 6 libraries & rules but not the compiler

[hszforu]

ok Thanks both of you.