the source programming oxygen org open jdt gratis descargar compiler compilador community java eclipse eclipse-jdt

java - programming - eclipse the eclipse foundation open source community website



Eclipse-"jerarquía de llamadas abiertas" obtuvo un resultado incorrecto (2)

Creo que puede ser el mismo problema que este error existente (aunque su ejemplo es más simple, IMO). Le sugiero que agregue un comentario y su ejemplo a ese informe de error.

Además, ¿podría estar relacionado con https://bugs.eclipse.org/bugs/show_bug.cgi?id=123836 que se sospecha como culpable de otro, https://bugs.eclipse.org/bugs/show_bug.cgi?id=394475

Aquí está mi código Java de muestra:

public class Test { public static void foo() { Foo.InnerKey key = new Foo.InnerKey(); getInstance().query(key); } public static void bar() { Bar.InnerKey key = new Bar.InnerKey(); getInstance().query(key); } public static MyIF getInstance(){ // TODO code to get instance return null; } } interface MyIF { public void query(Foo.InnerKey key); // Method to open call hierarchy public void query(Bar.InnerKey key); } class Foo { static class InnerKey {} } class Bar { static class InnerKey {} }

Cuando abro la jerarquía de llamadas de la query(Foo.InnerKey key) de métodos query(Foo.InnerKey key) desde Eclipse (kepler), obtuve ambos métodos foo y bar , cuya bar no se espera.

Pero en netbeans (7.3.1), el resultado de la jerarquía de llamadas es correcto:

¿Es un error de Eclipse? Gracias.


Este es definitivamente un error JDT que debe ser reportado. Y el error no está directamente relacionado con la jerarquía de llamadas, sino que con la API de búsqueda org.eclipse.jdt.core, cuando se buscan referencias de métodos, donde el parámetro es un tipo de miembro de otro tipo (como, por ejemplo, Foo.InnerKey ). Por lo tanto, este error se manifiesta para cada funcionalidad JDT, que se basa en la búsqueda de referencias de métodos utilizando el motor de búsqueda JDT. Por ejemplo, también obtendrá resultados erróneos al mostrar las referencias a la MyIF#query(Foo.InnerKey) o al usar la búsqueda de Java, para buscar el método MyIF#query(Foo.InnerKey) . En estos casos, el motor de búsqueda no solo devolverá referencias a la MyIF#query(Foo.InnerKey) , como se esperaría, sino también a la MyIF#query(Bar.InnerKey) .

El código relevante, donde ocurre este error, está en org.eclipse.jdt.internal.core.search.matching.MethodLocator#matchMethod(MethodBinding, boolean) . Y parece que el error se introdujo al corregir el error 41018 de JDT .

Aquí hay un fragmento del código relevante en la clase MethodLocator:

protected int matchMethod(MethodBinding method, boolean skipImpossibleArg) { [...] // verify each parameter for (int i = 0; i < parameterCount; i++) { TypeBinding argType = method.parameters[i]; int newLevel = IMPOSSIBLE_MATCH; if (argType.isMemberType()) { // only compare source name for member type (bug 41018) newLevel = CharOperation.match(this.pattern.parameterSimpleNames[i], argType.sourceName(), this.isCaseSensitive) ? ACCURATE_MATCH : IMPOSSIBLE_MATCH; } else { // TODO (frederic) use this call to refine accuracy on parameter types // newLevel = resolveLevelForType(this.pattern.parameterSimpleNames[i], this.pattern.parameterQualifications[i], this.pattern.parametersTypeArguments[i], 0, argType); newLevel = resolveLevelForType(this.pattern.parameterSimpleNames[i], this.pattern.parameterQualifications[i], argType); [...] } } [...] }

El problema aquí es la if (argType.isMemberType()) , que se introdujo para corregir el error 41018 . El comentario también establece que para los tipos de miembros solo se compara el nombre de la fuente . Si se elimina esta instrucción if, el error desaparece y la jerarquía de llamadas muestra las referencias correctas (pero supongo que esto volvería a introducir el error 41018, no probé esto).

Editar

En una nota al margen, también parece haber un error al mostrar los códigos fuente Javadoc para la MyIF#query(Bar.InnerKey) de MyIF#query(Bar.InnerKey) , tanto al usar el Javadoc-Hover sobre el método como al mostrar el método en la vista Javadoc.

public interface MyIF { /** * Javadoc for: query(Foo.InnerKey key) */ public void query(Foo.InnerKey key); // Method to open call hierarchy /** * Javadoc for: query(Bar.InnerKey key) */ public void query(Bar.InnerKey key); }

Cuando se desplaza sobre una referencia de método de consulta en la clase Prueba (por ejemplo, getInstance().query(key) ), se encuentran ambos métodos y uno puede seleccionar uno (sin la capacidad de diferenciar entre los dos).

Al abrir la vista de Javadoc y seleccionar cualquiera de las referencias de métodos de consulta en la clase de Prueba, la vista de Javadoc siempre muestra solo el Javadoc del primer método encontrado en la clase de origen (es decir MyIF#query(Foo.InnerKey) ).

Esto no parece estar directamente relacionado con el error descrito anteriormente, y tampoco se resolverá al eliminar la sentencia if mencionada anteriormente ...