Summary: | [1.5][search] Search for method declaration doesn't find method with instantiated type parameters | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Markus Keller <markus.kell.r> | ||||||
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | dirk_baeumer, philippe_mulet | ||||||
Version: | 3.1 | ||||||||
Target Milestone: | 3.1 RC1 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Bug Depends on: | 75642 | ||||||||
Bug Blocks: | 79976 | ||||||||
Attachments: |
|
Description
Markus Keller
2004-12-02 06:44:11 EST
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... *** 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 |