Community
Participate
Working Groups
There is currently no way to search for exact references X.y(). Here is my concrete use case: in the SDK we have: IResouce.isReadOnly() IFile.isReadOnly() where IFile extends IResouce My goal is to find all calls that use the deprecated method i.e. all cases where the isReadOnly() is called on a variable declared as IResouce. Of courese there might be Foo implementing IResouce, but I can live with a result that does not report those, as long as I can then search for Resource.isReadOnly() later and find all calls to isReadOnly() made on varibables of type Resource.
Note that the search for IResource.isReadOnly() is severely broken in I20071107-1300, see bug 209054.
Search Engine currently sets and carries a new flavor on the found references to indicate that it's a sub invocation of the searched method . However, this flavor is not set to the MethodReferenceMatch. So, the solution may be to add this flavor to the MethodReferenceMatch as we did for the super invocation flavor a little while ago. User then might filter in the Search View this kind of matches and avoid to see references to IFile.isReadOnly()... In this peculiar search request, the other possibility would be to add this kind of search as another template (bug 110157) or fine grain (bug 155013) to specify that user only looks for deprecated types/methods/fields...
Filter approach sounds good to me.
Yes, MethodReferenceMatch#isSubInvocation() sounds good.
This would be a good candidate for the fine grained search (depending on how you interpret fine grained).
(In reply to comment #5) > This would be a good candidate for the fine grained search (depending on how > you interpret fine grained). > Currently not. To improve performances, the fine grain search is now completely done while parsing the compilation units. At this early stage, no resolution is done on the AST nodes and there's no way to know anything about the sub-invocation flavor as it is only available while resolving the AST nodes...
Seems to be similar to my problem: I was looking for java.util.concurrent.FutureTask.run but all run call were found from all super interfaces, (i.e. Runnable.run), giving me hundreds of false positives. Still an issue in 3.7 and 4.2...
(In reply to comment #7) This is a different case that has been solved with bug 157814, see the "References to Overridden" filter in the Search view menu. Bug 157814 added the search filter to exclude references to overridden methods, but that's the reverse of what comment 0 asked for. At least since 3.6.2, this problem is only reproducible on an abstract method. Search for references to an abstract method also finds references to overriding or implementing methods. In contrast, search for references to a concrete method does not report references to overriding methods ("r.isR()" below). I don't see why the search engine should return references to overriding abstract methods but not to overriding concrete methods. The two cases should be treated equally. A different implementation doesn't make a method more different than an abstract re-declaration (which could add annotations, change return type, etc.). public class Text { void res(R r, IR ir) { r.isR(); r.isAR(); ir.isIR(); } void file(F f, IF iff) { f.isR(); f.isAR(); iff.isIR(); } } abstract class R { boolean isR() { return false; } abstract boolean isAR(); } abstract class F extends R { boolean isR() { return true; } abstract boolean isAR(); // boolean isAR() { return false; } } interface IR { boolean isIR(); } interface IF extends IR { boolean isIR(); }
