Community
Participate
Working Groups
I20041130 Code select now return a special IJavaElement when resolving code list List<String>. If we hand such an element over to the search engine we need means to distinguish between searches for List and searches for List<String>. One idea is to add additional flags to SearchPattern.
Also the search match should persist the fact it was a strict match vs. a raw match, for filtering at a later stage (think of filter in search result view).
I've open bug 79866 for comment 1 request...
Fixed. SearchPattern now accepts a new flag for match rule: R_ERASURE_MATCH. When this flag is set, search engine founds all types whose erasure matches the given pattern erasure. By default search engine will only find exact or compatible matches for generic or parameterized types. Added new API method to make this flag settable even while creating pattern using a IJavaElement: SearchPattern#createPattern(IJavaElement,int,int) SearchMatch now has a rule field which shows the rule used while reporting the match (see bug 79866 comment 1) [jdt-core-internal] I'll attached patches if someone is intererested in looking at changes... New test class added: JavaSearchGenericTypeErasureTests Note that JavaSearchGenericTypeTests has been fully rewritten due to the fact that the output was completely modified with this new flag (display search match compatibility and erasureness) .
Verified in 200412140800