Community
Participate
Working Groups
consider the following classes: public interface IBarable { public void bar(); } public class Foo { public void bar() {} } public class SubFoo extends Foo implements IBarable { } When trying to find all implementations of IBarable#bar, Eclipse doesn't notice that SubFoo implements it by inheriting it from Foo. I notice that this is somewhat questionable style anyway, but when working with legacy code, it can be fundamentally important to understand the code. It would be nice, for example, if the type hierarchy (using ctrl-t on the method declaration in the interface) could show SubFoo implementing the method, somehow indicating that it does inherit it (perhaps by showing it in a different color, using the override indicator or something).
Similarly, finding references doesn't work on the implementation in Foo: public class Test { public void test() { IBarable barable = new SubFoo(); barable.bar(); } } Using ctrl-shift-g on Foo#bar doesn't find the reference in Test#test (which it does when foo directly implements IBarable).
Parts of this has to be provided by the search engine. CC JDT/Core.
Implementing and inherting are two diffenert things. So, IMO, you can't say that SubFoo 'implements' bar. The type hierarchy has the option to show all inherited members. The problem with the code example in comment 1 is that barable is of declared type IBarable. Searching for references of Foo:bar should match references to IBarable:bar. It should match for SubFoo:bar, but that's not the case here. Maybe I misunderstood your request. Setting to remind as I don't know what we could improve here.
(In reply to comment #3) > Implementing and inherting are two diffenert things. So, IMO, you can't say > that SubFoo 'implements' bar. It's probably sloppy terminology, yes. I think you understood me nevertheless... ;) > The type hierarchy has the option to show all inherited members. I don't see how that helps me with my problem. Imagine that I want to change the method signature of IBarable.bar(). As far as I can tell, there is currently nothing in Eclipse that helps me find out that Foo.bar() might be affected, other than possibly a compile time error.
(In reply to comment #4) > > The type hierarchy has the option to show all inherited members. > > I don't see how that helps me with my problem. > > Imagine that I want to change the method signature of IBarable.bar(). As far as > I can tell, there is currently nothing in Eclipse that helps me find out that > Foo.bar() might be affected, other than possibly a compile time error. > That's wrong, with your example, if you rename bar() method from Foo class, then you are informed that this method implements an interface and you're asked if you want to perform the rename from the interface IBarable instead... Then 'barable.bar()' will be also renamed as it has been declared as an IBarable object...
(In reply to comment #1) > Similarly, finding references doesn't work on the implementation in Foo: > > public class Test { > public void test() { > IBarable barable = new SubFoo(); > barable.bar(); > } > } > > Using ctrl-shift-g on Foo#bar doesn't find the reference in Test#test (which it > does when foo directly implements IBarable). Unfortunately there's nothing Search Engine currently can do about this kind of search request. As said Martin, 'barable' is declared as 'IBarable' and so, as S.E. uses declarations while searching for fields/methods/types, it cannot get 'barable.bar()' as a reference match for 'Foo.bar()' pattern. This is a similar problem than following test case: class Foo { void foo(Object obj) {} void bar() { foo("hello"); } } Although the call 'foo("hello")', Search Engine does not find any reference to 'foo(String)' method pattern. Even with a String parameter, method declaration is still 'foo(Object)' and it obviously does not match this pattern...
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
*** Bug 328488 has been marked as a duplicate of this bug. ***
This request is still valid for me, but I don't have permission to reopen it. Please reopen it.
We have no plans to show inherited implementations from side branches in the type hierarchy. For one, they don't belong there technically, and secondly, this would be too expensive to compute in the general case (see also bug 328488 comment 1). Setting this bug to WONTFIX. As a remedy, we could add a Clean Up that adds explicit implementations of "joiner" methods where they are missing. For the example in comment 0, it would add this to SubFoo: public void bar() { super.bar(); } If you think that would be useful, please file a new enhancement request.
(In reply to comment #10) > If you think that would be useful, please file a new enhancement request. I just hit such a case myself and filed bug 328760 to request this Clean Up. The problems I had there were actually not in the type hierarchy but in the search engine (comment 1).
*** Bug 67012 has been marked as a duplicate of this bug. ***
*** Bug 413285 has been marked as a duplicate of this bug. ***
*** Bug 112917 has been marked as a duplicate of this bug. ***
*** Bug 228541 has been marked as a duplicate of this bug. ***
*** Bug 268763 has been marked as a duplicate of this bug. ***
*** Bug 270231 has been marked as a duplicate of this bug. ***
