Bug 204893 - [search] fake overridden method and search references
Summary: [search] fake overridden method and search references
Status: VERIFIED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4 M3   Edit
Assignee: Frederic Fusier CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-28 04:49 EDT by Adrian CLA
Modified: 2007-10-29 08:44 EDT (History)
2 users (show)

See Also:


Attachments
Package Explorer showing a false inherited overridden method (30.67 KB, image/jpeg)
2007-09-28 04:49 EDT, Adrian CLA
no flags Details
Hierarchy view showing a fake inherited overridden method (24.60 KB, image/jpeg)
2007-09-28 04:50 EDT, Adrian CLA
no flags Details
Search view showing an unexisting reference for a method (14.67 KB, image/jpeg)
2007-09-28 04:51 EDT, Adrian CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian CLA 2007-09-28 04:49:14 EDT
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
Comment 1 Adrian CLA 2007-09-28 04:50:17 EDT
Created attachment 79357 [details]
Hierarchy view showing a fake inherited overridden method
Comment 2 Adrian CLA 2007-09-28 04:51:13 EDT
Created attachment 79358 [details]
Search view showing an unexisting reference for a method
Comment 3 Martin Aeschlimann CLA 2007-09-28 12:06:23 EDT
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.
Comment 4 Frederic Fusier CLA 2007-09-28 15:39:12 EDT
(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?
Comment 5 David Audel CLA 2007-10-01 04:32:57 EDT
Selection Engine doesn't return a resolved java element when a declaration is selected for performance reasons (see bug 66271).
Comment 6 Frederic Fusier CLA 2007-10-01 07:09:01 EDT
(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)");
           }
       }
Comment 7 David Audel CLA 2007-10-29 08:44:15 EDT
Verified for 3.4M3 using I20071029-0010 build.