Community
Participate
Working Groups
Build ID: 3.4.0 Steps To Reproduce: 1) define 3 projects: rootProject, subProject1, and subProject2. 2) set project build depedencies such that subProject1 and subProject2 depend on rootProject 3) Create interface in rootProject: public interface Shape { public void f(); } 4) Create implementing class in subProject1 public class Square implements Shape { public void f() {} } 5) Create referencing class in subProject2 public class ShapeUser { public void useShape(Shape p_shape) { p_shape.f(); } 6) Search for references to Square.f() directly from it's declaration in Square.java. 6a) EXPECT: one result: ShapeUser.useShape(Shape) 6b) ACTUAL: no results If ShapeUser is instead located in the direct derivable project dependency graph for subProject1, the results are ok. For example, 1) If Square were defined in rootProject itself, the search succeeds. 2) If Square were defined in subProject2, the search succeeds. 3) If subProject2 has a build dependency on subProject1, the search succeeds. Additionally, searching for references to f() from the Shape declaration succeeds as defined above. It appears the search does not go to all dependent projects of the project declaring the interface. More information: Also reproduced this bug on 3.3.1.1 (earliest version available to me) This is related to Bug#: 178596, which is closed with Eclipse 3.3, but when this problem recurs when the project dependencies are as described above.
The problem comes from the fact that search engine first looks at projects concerned by the search to know which indexes should be activated... In this case the current algorithm in IndexSelector.initializeIndexLocations() does not consider that subProject2 can see the focus. The problem is tricky at this stage, as the index selector knows nothing about the hierarchy of the declaring class of the searched method. Several ways may be envisaged to fix this issue but they would have all impact on performances: 1) look at resolved classpath of each project of the scope and keep it as soon as one entry is common with the focus project 2) look at focus declaration class super type hierarchy and either starts the search from the root type or walk through the whole hierarchy and keep indexes for all projects of it 3) include all indexes when the search is done on the workspace I'll try to figure out what could be the performance impact for 2) and 3). Proposal 1) is currently a no go because either jars are not included and there would be still use case where the references wasn't find or the jars are included and then all projects would be added due to JRE and PDE containers...
*** Bug 264153 has been marked as a duplicate of this bug. ***
Created attachment 125382 [details] Proposed patch
(In reply to comment #3) > Created an attachment (id=125382) [details] > Proposed patch > I forgot to mention that I didn't notice any noticeable performance regression with this patch.
Released for 3.5M6 in HEAD stream.
*** Bug 240790 has been marked as a duplicate of this bug. ***
Verified for 3.5M6 using I20090309-0100.
