Community
Participate
Working Groups
I20041130-0800 Search for method declaration doesn't find method with instantiated type parameters: class X<T> { public void method(Number num) {} public void other(T t) {} } class Y extends X<Number> { public void method(Number num) {} public void other(Number t) {} } Search for declarations of X#method(Number) gives 2 matches. Search for declarations of X#other(T) gives only 1 match. Is this the intended behavior? IMO, Y#other(Number) should also be found, since it overrides X#other(T).
Support for generic/parameterized type in methods search is not currently finalized (see bug 75642).
Even with bug 75642 fix, we could not do anything yet on this peculiar issue without having any further information. Currently, while locating method matches, there's an initial filter which removes all possible matches found in indexes which do not have same selector and parameters types name. In this case, other(Number) is removed because parameter 'T' is different than 'Number'. Unfortunately, we cannot remove as this is a low level filter. Without it, locating would be polluted by many additional matches and this would have a performance impact on search results. I have to think a little bit more to figure out what could be possible solution to address this issue...
Perhaps related to bug 80264?
*** Bug 83818 has been marked as a duplicate of this bug. ***
Here's a similar, but slightly different case: class Super<T> { void methodT(T t) {} } class Sub<X> extends Super<X> { void methodT(X x) {} // overrides Super#methodT(T) } Note: this PR is case (2) of bug 81377.
Frederic - you could imagine find super method matches by walking super hierarchies once you found a good match.
Tagged for M7 tentatively, but could be done during first release fixpass cycle. Dirk said: "this bug is important for us since your new ripple method implementation needs this bug fixed"
Finally syntax filter will be removed on parameter names as it concerns only a limited number of matches (selector and number of arguments still should match pattern).
Too risky for M7 without measuring impact on performances for potential fix... => defer to RC1 (hopefully early)
Created attachment 21125 [details] Patch to implement this fix Testing performance of this patch for this specific method search (java.lang.Object.equals(Object) on a workspace with only org.eclipse.jdt.core project) shows that time spent in MethodLocator.matchOverriddenMethod is negligible (ie. less than 5ms although whole search lasts ~26 seconds) as it does not appear in hierarchy calls below MethodLocator.resolveLevel: 3.55% - 860 ms - ...search.matching.MatchLocator.reportMatching() 3.27% - 790 ms - ...search.matching.MatchLocator.reportMatching() 0.22% - 55 ms - ...search.matching.MethodLocator.resolveLevel() 0.22% - 55 ms - ...search.matching.MethodLocator.resolveLevel() 0.14% - 35 ms - ...search.matching.MethodLocator.resolveLevelAsSubtype() 0.08% - 20 ms - ...search.matching.MethodLocator.matchMethod() 0.02% - 5 ms - ...search.matching.MatchingNodeSet.addMatch()
Ooops, I'm really tired by the end of this milestone week... Forgot time results in previous comment, I've made a reference search although the fix is only active while searching declarations...:-( As expected, when performing some specific string pattern search, we can observe a decrease of performance. Typically for string method pattern "e*(Object)" on org.eclipse.jdt.core project: without fix search lasts ~33s although it takes ~42s with the fix. This 27% of time over cost is spent while resolving some of compilation units although it was never done before for this pattern... However note that it's only the case for a limited kind of search: string method pattern with type non qualified arguments... For other kind of method declaration searches (typically thoses of two test cases described in comment 0 and comment 5), time over cost is only due to resolution in declaring type hierarchy to find if match may override generic methods. Performance tests I've done while searching for IMethod "equals(java.lang.Object)" in project org.eclipse.jdt.core. show that there's no noticeable time over cost for this extra resolution... So, I'm now confident about this patch and will release it as soon as 3.1 M7 will be declared (ie.tomorrow).
philippe, do you agree with this fix even if it can decrease performance on certain seldom kind of method search ?
I forgot to mention that this fix (ie. resolve + look at super classes and super interfaces hierarchy) is only activated for 1.5 source level. That means all previous search in 1.4 mode still works as before and does not get any time penalty due to this fix. This reduce a lot cases concerned by -27% performance results related in comment 11.
Created attachment 21157 [details] Patch to implement this fix without time penalty This is a new version for the fix which does not need to resolve with string method pattern. With this patch, while creating pattern, we just look if method type arguments is equals to one of declaring type type parameters. If so, then set a specific flag to: 1) ignore syntax filter 2) parse super classes and interfaces hierarchy on each possible match With this fix searching method declaration with "e*(Object)" pattern gives same times than 3.1 M7. All JDT/Core and JDT/UI tests pass with this fix
Fixed. Second patch was released in HEAD. [jdt-core internal] Test cases added in JavaSearchBugsTests
Verified in I20050526-2000
