Community
Participate
Working Groups
Created attachment 79356 [details] Package Explorer showing a false inherited overridden method Suppose we have the following two classes defined in two different packages, generic and implementation: package generic; public class A { public void method(A a) { System.out.println("generic.A(generic.A)"); } } and package implementation; public class A extends generic.A { public void method(A a) { System.out.println("implementation.A(implementation.A)"); } } Please note the followings: - class implementation.A extends the class generic.A - the method generic.A.method takes an argument of type generic.A - the method implementation.A.method takes an argument of type implementation.A - therefore the method implementation.A.method does NOT override the method generic.A.method since their signatures are not the same (different parameter types) But, when looking in Package explorer, we can see that the Eclipse workbench shows that the method implementation.A.method overrides the method generic.A.method, although this is false. If we open the class implementation.A in the editor, there is no sign on the left that the method would be overridden, which is correct. Please see the attached file package_explorer_view.JPG The same in the hierarchy view when selecting implementation.A.method and pressing "Lock view and show members in hierarchy" button. Please see the attached file hierarchy_view.jpg Suppose we define the following test class in the default package (or whatever): public class B { public static void main(String[] args) { generic.A a1 = new generic.A(); a1.method(a1); } } Please note the followings: - the class B _does not use_ the class implementation.A - the class B _uses_ the class generic.A - the class B invokes the method generic.A.method When we open the class implementation.A and we perform a search for references in the workspace for the method implementation.A.method, then there is one reference found, in the class B, method main, which is obviously false, class B never uses implementation.A.method. Please see the attached file search_view.JPG
Created attachment 79357 [details] Hierarchy view showing a fake inherited overridden method
Created attachment 79358 [details] Search view showing an unexisting reference for a method
The type hierarchy and the override indicators only use the simple names for parameter types to evaluate if a method overrides. This is for performance reasons. Reference search however should be precise. Moving to jdt.core.
(In reply to comment #3) > The type hierarchy and the override indicators only use the simple names for > parameter types to evaluate if a method overrides. > This is for performance reasons. > > Reference search however should be precise. Moving to jdt.core. > The given IJavaElement while creating the SearchPattern is not resolved. So, there's currently no way for SearchEngine to be more precise with this missing information. In order to have parameter type qualification, Selection Engine should return a resolved java element in this peculiar use case. David, what's your mind about this?
Selection Engine doesn't return a resolved java element when a declaration is selected for performance reasons (see bug 66271).
(In reply to comment #5) > Selection Engine doesn't return a resolved java element when a declaration is > selected for performance reasons (see bug 66271). > So, there's no way for Search Engine to distinguish the matches as parameter type will never be qualified... So, close this bug as WONTFIX for the following reasons: 1) change current Selection Engine behavior might have huge performance regression (see bug 66271 comment 12) 2) this test case (i.e. having same class names in the hierarchy) should really seldom happen in the real world 3) qualifying the method declaration in sub-class fixes the problem: package implementation; public class A extends generic.A { public void method(implementation.A a) { System.out.println("implementation.A(implementation.A)"); } }
Verified for 3.4M3 using I20071029-0010 build.