Community
Participate
Working Groups
I have a class Obstacles extends Rectangle, which overrides containsPoint(int, int). I would like to search to references to this method. When I search, I get all references to Rectangle#containsPoint(int, int) instead. How can I make this search? Which method is the bytecode calling?
We do a polymorphic search since there could be variables of type Rectangle actually valued to instances of Obstacles, e.g.: Rectangle r = new Obstacles(...); r.containsPoint(...) However, this should not result in looking for senders of Rectangle.containsPoint, as it should eliminate matches to other subtypes of Rectangle (i.e. not in the branch of Obstacles). Ok to close?
I don't want to close because I am unable to do what I need. What is the generated bytecode for: Obstacle o = new Obstacle(x, y, w, h); o.containsPoint(point); ?? Is it a call to Obstacle#containsPoint(), or Rectangle#containsPoint(..)? I want to search for all places where the compiled bytecode refers to Obstacle#containsPoint(..), and this isn't possible. The polymorphism makes sense usually, but in my specific case Obstacle is never cast to or referred to as a Rectangle. It is simply for convenience that it inherits some of the utility method on Rectangle. BTW, is there a way to search for casting of a type to its supertype??
I agree this polymorphic search is sometimes annoying when you're sure that you do not want it! I guess we can think about a new option in search to activate it or not, I'll put this in my list... About search for a cast, it's not possible for now, but bug 73205 addresses this request.
Unfortunately, I'll not have enough time to add this option... Defer post 3.1
Reopen for 3.2
*** Bug 85347 has been marked as a duplicate of this bug. ***
*** Bug 105768 has been marked as a duplicate of this bug. ***
The polymorphic search is very annoying when searching with wildcards. For instance searching for references to SomeClass.get* will find all the references to Object.getClass() - when all I want is references to the getters defined in SomeClass.
Is there any change it'll get fixed soon? It's so very problematic when I want to find references or declarations of a method which I know should be found in three or four places in a project but instead get hundreds of hits from packages like com.ibm.icu or com.sun.corba and all irrelevant places from all over the project. :/
*** Bug 116208 has been marked as a duplicate of this bug. ***
*** Bug 121016 has been marked as a duplicate of this bug. ***
*** Bug 108219 has been marked as a duplicate of this bug. ***
Unfortunately, this new option was missed for 3.2 and needs to be deferred again. I've tagged it 3.3 + [API] to avoid doing this error twice. Sorry for the delay...
Reopen as the pressure get more and more important on this problem (see bug 156941 comment 2)...
I'd rather prefer a new flavor on SearchMatch to allow user to filter polymorphic matches than a specific pattern. Having a specific pattern would not save too much time as the filter could only be applied while resolving possible matches (ie. just before creating SearchMatch to report it).
A flag on SearchMatch sounds good. JDT/UI can then easily add a filter for polymorphic matches to the search result view. BWT: comment 14 meant bug 156491. Will the 'polymorphic' flag be set for matches deeper down in the hierarchy as well? I.e. if I expand comment 0 and add a class MyObstacles that extends Obstacles and overrides containsPoint(int, int) again, will calls to myObstacle.containsPoint(..) be considered polymorphic or not? Or do we even need 2 flags here?
(In reply to comment #16) > A flag on SearchMatch sounds good. JDT/UI can then easily add a filter for > polymorphic matches to the search result view. BWT: comment 14 meant bug > 156491. Ooops, thanks > > Will the 'polymorphic' flag be set for matches deeper down in the hierarchy as > well? I.e. if I expand comment 0 and add a class MyObstacles that extends > Obstacles and overrides containsPoint(int, int) again, will calls to > myObstacle.containsPoint(..) be considered polymorphic or not? Or do we even > need 2 flags here? > In patch I provided in bug 156491 comment 9, these kind of matches are not flagged as polymorphic. However, it's not a big deal to do it. The only remaining questions are: is it really necessary and f so, is it important to distinguish if the polymorphism comes from superclasses or subclasses...??? I can't see any use cases where it could be necessary but I'm sure you have something in mind, haven't you?
Created attachment 50171 [details] Proposed patch This patch include also fix for bug 156491. Note that JDT/UI needs to implements corresponding filter in Search View to have this issue completely fixed...
JDT/Core patch released for 3.3 M2 in HEAD stream. Wait for JDT/UI input to set this bug as fixed...
I've released a filter for polymorphic matches to the Java search result page. The filter is enabled automatically in new workspace. Re comment 17: Methods declared in subtypes as well as methods declared in supertypes are polymorphic matches now. Just 1 flag for all.
Verified for 3.3 M2 using build I20060918-0010.
>The filter is enabled automatically in new workspace. This is is no longer true. See bug 157814 for details.
*** Bug 116295 has been marked as a duplicate of this bug. ***
