var-args overloading compiler error: ambiguous

[Tom Reilly]

I tried a test where I overloaded a function using var-args. One
function expected a list of long values and the other expected a list of
Integers. The compiler complained when I tried to use the Integer
version:

The method widen(long[]) is ambiguous for the type WideningAndBoxing

The line about which the compiler complained is a call to widen() with
three Integer parameters, which is the second function (below).

Why does the compiler see this as ambiguous?

 
public class WideningAndBoxing
{
        public static void widen(long...ls)
        {
                System.out.print("Widen(long...): ");
                for (long l : ls)
                        System.out.print(l + " ");
                System.out.println();
        }

        public static void widen(Integer...is)
        {
                System.out.print("Widen(Integer...): ");
                for (Integer i : is)
                        System.out.print(i + " ");
                System.out.println();
        }

        public static void main(String[] args)
        {
                long l = 25;
                Integer integer = new Integer(10);
                
                widen(l, l, l);
                widen(integer, integer, integer);   // compiler error
        }
}

[Sahil Kapoor]

IMO : When there is a case of var-args conflict, then widening and Boxing are of same priority. You cannot say that first compiler would try to Widen then Box.

Now in your widen method you have conflict of var-args.

Your call matches widen (Integer....) if Boxed
Your call matches widen (long....) if widened

and hence compiler shows ambiguity.

[Tom Reilly]

Thanks for your reply. My point is that the compiler had to both unbox and then widen in order to find the ambiguous condition. If it had done neither it would have recognized the method.

[Abimaran Kugathasan]

When overloading, (widening + var-args) and (Boxing + var - args) can only be used in a mutually exclusive manner. Not together...

[Tom Reilly]

Your call matches widen (Integer....) if Boxed
Your call matches widen (long....) if widened

I agree that calling widen(100, 200, 300) would be ambiguous. But the offending statement uses Integer - not int. So it would not have to box nor widen to find widen(Integer...is).

[Jeanne Boyarsky]

Interestingly if you have Integer... and Long..., you don't get the error. I don't understand why Integer is getting unboxed and then expanding to long... though.

[Tom Reilly]

FYI, I downloaded the latest JDK (jdk 1.6.0_21) and it does not produce the compiler error. My previous version was 1.6.0 but I don't remember the revision. (I downloaded the latest version for other reasons and was pleasantly surprised to find this issue resolved.)