Community
Participate
Working Groups
Please consider this code: public class SearchForReferences { interface SomeInterface { void foo(); } class A implements SomeInterface { public void foo() {} // <-- click on foo() and search for references } class B implements SomeInterface { public void foo() {} } class C { void bar() { new A().foo(); } } class D { void bar() { ((SomeInterface)new B()).foo(); } } } When searching for references to A.foo() Eclipse finds two matches, one in class C and one in class D. It would be ok if it was search for method SomeInterface.foo() but it's a search for method A.foo() This may sound trivial but when working on larger projects with large number of classes implementing an interface search for references to a class method becomes basically useless. Ugly workaround is to comment list of implemented interfaces.
This search behavior exists since the beginnning... Class D is equivalent to: class D { void bar() { SomeInterface x = new B(); x.foo(); } } and it's definitely normal that search returns a match on 'foo' of x.foo()... So, in your example, match is found in D due to explicit cast to interface which *does* implement the method and theoretically could be an instance of A... For example, search returns only one match if you would have searched for foo references from class B. However, I agree that looking at statement: ((SomeInterface)new B()).foo(); it's obvious that, even with explicit cast, we know the instance is not an instance of A... I'll have a look if it wouldn't be possible to make search smartter in this case and avoid to return a match... May you reduce severity of bug as there's a workaround which seems not ugly to me? If you modify class D as follow: class D { void bar() { new B().foo(); } } search won't find this match.
Well, I'm afraid the problem is real and has no general workaround. Similar to the problem I originally posted is code below: public class ToString { class A { // place cursor on toString() and search for references @Override public String toString() { return ""; } } class B { B() { new A().toString(); // reference found here } String foo(Object o) { return o.toString(); // and here too } } } Searching for A.toString() finds each and every reference to A.toString() and Object.toString() methods in all currently opened projects. This can be a lot of matches, vast majority of which would be false positives.
Again, this is intentional. In your previous comment sample, o may be an instance of A at runtime and so search has to report "o.toString()" as a match. In this case, this is not interface implementation but class inheritance. I agree that in this case, there's no workaround but no real problem either as we cannot infer from code what would be the class at runtime...
I suggest to change this bug as an enhancement which would propose a specific flavor for this kind of match and allow user to filter them in Search view (same behavior than for matches in Javadoc or inexact/incompatible generic matches...)
Well, I may not see why it's not a bug but for me, a mere user, it is :-) I asked program to search for references to a method of some particular class, not methods of interface it implements or its superclass. If I wanted to search for interface or superclass methods I'd do so. But of course you're the one who knows how a particular submission should be treated :-)
*** Bug 85347 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 73401 ***
