Bug? Ambiguous error on overloaded varargs

Question

Hi!
I don't understand why the following code throws an ambigous error.
I simply create two same-named methods using varargs, one time for int, one time for float.
If I call it I would suppose that it is resolved in the same way as always on overloaded methods, i.e. the first example should call the int... - version, the third the float...
But Java throws an ambiguous error at compile-time, though an implicite cast from int to float is not neccessary if all parameters are pure int. Further no error is thrown when passing an int[]-array.
This seems to me like a kind of bug. I'm using version 1.5.0_06
public class TempTest {
     public static int getFirst(int... A) {
          return A[0];
     public static float getFirst(float... A) {
          return A[0];
     public static void main(String args[]) throws Exception
          System.out.println(getFirst(1,2,3)); // throws ambiguous-error during compilation
          System.out.println(getFirst(new int[]{1, 2, 3})); // works as suspected for int
          System.out.println(getFirst(1f,2,3)); // works as suspected for float
          System.out.println(getFirst(new float[]{1, 2, 3})); // works as suspected for float
}

Answer 1

Ok, I read the chapter but I don't see the reason for this behaviour. Let's assume another more clear example:
There are simply two methods for finding the maximum of the passed parameters, either passed as int or float
public class TempTest {     
     public static int max(int... a) {
          int max=a[0];
          // find the max of all
          return max;
     public static float max(float... a) {
          float max=a[0];
          // find the max of all
          return max;
     public static void main(String args[]) throws Exception
          max(1,2,3,4,5); // ambiguous, though calling int[] suspected
}I understood the section 15.12 as follows:
1. find accessible and applicable methods, here both max(int...a) and max(float...a) will do it
2. try to find a most specific of them:
Assuming that an implicite cast is handled as e.g. int <: float in 15.12.2.5 it is that int[] <: float[] but NOT that float[] <: int[].
Therefore max(int...a) is strictly more specific and maximally specific, so it should be used, and no ambiguous error thrown.
So it seems that my assumption that implicite type-casting is handled in the same manner as e.g. int <: float is wrong, though I don't know why.
In my opinion the whole varargs-concept is more or less useless, if you cannot overload a method with them like e.g. max(int... a) and max(float... a), though intuitively it is absolutely clear, that calling max(1,2,3,4) or e.g. explicitely max((int) 1, (int) 2, (int) 3) should call the int-version or any other that is nearest in implicite type-casting.
So at least pragmatically I cannot be reasonable as long as I don't see any clear reason for that methodcall being ambiguous.
[EDIT]
I think I got the problem now:
Though int <: float it is NOT true that int[] <: float[]. Simple because:
int i = 3;
float f = i; // ok
int[] iarr = new int[4];
float[] farr = (float[]) iarr; // not possibleThis seems to be the problem when finding the most specific method, because it is neither int[] <: float[] nor float[] <: int[], so ambiguous.
I see the problem now:
It is (nearly) impossible to convert between arrays of primitives when passing them by reference. Imagine: changes to the converted referenced array should have to be written back to original array of other primitive type!
But then there >should< have be done any other trick when implementing varargs, because as mentioned before it is just a silly feature if it is not possible to overload in such a simple manner as max(int... a) with max(float... a)
[EDIT]
Message was edited by:
wagalaweia