2012-06-01 5 views
15

he definido:"método es ambiguo para el tipo", pero los tipos no son ambiguas (y el error viene de actualización de Eclipse 3.7.2 eclipsar 4.2)

public static int[] getArray(final int... params) { 
    return params; 
} 
public static <T> T[] getArray(final T... params) { 
    return params; 
} 

y yo uso esto en

getArray(1, 2) 

y ahora me sale en Eclipse 4.2 el error de compilación:

method is ambiguous for the type

Pero como se puede ver que esto no es ambigua. ¿Que puedo hacer?

+0

El compilador puede estar intentando aplicar el autoboxing, en cuyo caso no puede elegir ninguno de sus métodos. No estoy seguro, pero puede intentar emitir sus argumentos explícitamente: 'getArray ((int) 1, (int) 2)' –

+0

Etiquete con el lenguaje apropiado (Java? C#?). –

+1

Por cierto javac del JDK 1.7 está de acuerdo con eclipse 4.2 –

Respuesta

9

En realidad este es ambiguo porque Autoboxing en Java le permite llamar a un método que espera un int con un revés Integer y el vicio, por lo getArray(1, 2) realmente puede ser una llamada válida para cualquiera de sus métodos.

Según entiendo lo que estás haciendo, quieres tener un método de utilidad para crear una matriz de lo que sea. Tal vez lo más simple que puede hacer es cambiar el nombre del método que trata con int a getIntArray(). O simplemente use new int[] {1, 2} que es muy legible si quiere una matriz int.

Puede encontrar esta información en la especificación del idioma en http://docs.oracle.com/javase/specs/jls/se5.0/jls3.pdf (en su caso, determinar el método invocado irá al paso 3 del proceso descrito en la sección 15.12.2 Tiempo de compilación Paso 2: Determine la firma del método, porque utiliza la variable arity, y en el paso 3, ambas llamadas al método son válidas)

+0

no creo que esto esté claro. teníamos la misma configuración de proyecto que usa jdk6-compilance-level para compilar antes de la actualización a eclipse 4.2 (former Eclipse 3.7.2) y no tuvimos ningún error en la compilación. auto-boxing ya se utilizó en la configuración anterior. ¿Por qué la actualización trae este problema? – elb

+0

@ user1430985 Agregué una referencia a la especificación, que explica el comportamiento.Si creo en la especificación, su proyecto se volvió dependiente de un error en la versión anterior del compilador de eclipse. –

23

Esto se informó como un error en el eclipse bug 383780.
Aquí es la documentación de la revisión: https://bugs.eclipse.org/bugs/attachment.cgi?id=218320

Básicamente, para solucionar el error del compilador, obtener la última versión de Eclipse (4.2.1 a partir de ahora), agregue la siguiente línea después -vmargs en eclipse.ini: (a continuación, es posible que necesite para reiniciar Eclipse y proyectos de reconstrucción)

-DtolerateIllegalAmbiguousVarargsInvocation=true 

dicho esto, Samuel es correcta: la invocación del método es ambiguo. El ejemplo de código anterior funcionaba antes porque había un bug en JDK antes de 1.6; y el compilador personalizado en Eclipse imitó exitosamente este error. Al desarrollar Juno, corrigieron this bug (porque el error JDK se corrigió en 1.7) al informar la invocación ambigua como un error, molestando a muchas personas (incluyéndome a mí). La solución anterior le pide que explícitamente le diga a eclipse que "tolere la invocación ilegal de Varargs ambiguos".

Cuestiones relacionadas