Bug 320065

Comment 1 Olivier Thomann 2010-07-16 09:01:33 EDT

Are all the matches exact matches or potential matches ?

Comment 2 Eric Jain 2010-07-16 14:03:22 EDT

I'm using the default settings, so "Potential Matches" is not checked.

Even if it were, I don't think List.iterator() should be a potential match for HashSet.iterator()?

Comment 3 Satyam Kandula 2010-07-22 09:44:54 EDT

ArrayList being a class and List an interface is the reason behind this behavior. For better understanding of the special handling of interfaces, consider the following extension to your example. 
#########
class HashSet2 extends HashSet implements List{} 
#########
With this class in picture, there is a possibility that List.iterator may end up in HashSet.iterator(). Search Engine doesn't want to miss this references and hence it differs for interfaces. Look at bug 178596 and bug 157814 for more information. These results can be filtered by filtering 'References to Overriden'. 
Hope this helps.

Comment 4 Eric Jain 2010-07-23 01:30:32 EDT

I don't see an option to filter "References to Overriden" in the Java Search dialog (or elsewhere)?

Comment 5 Satyam Kandula 2010-07-25 23:43:54 EDT

Created attachment 175194 [details]
Location of viewmenu

Click on the View menu, triangle shaped and located near the top right hand corner of the the view or look at the attached image.

Comment 6 Eric Jain 2010-07-26 13:05:22 EDT

Thanks, found the option to filter "References to Overridden", works as expected. But I still don't quite follow the reasoning why List.iterator() should match on an unfiltered search for HashSet.iterator(). If the argument is that there could be a class HashSet2 that implements List, I'd also expect the following to result in a match:

  interface IFoo<E> {
    Iterator<E> iterator();
  }

  IFoo<E> foo = ...
  foo.iterator(); // no match!

...because there could be a class HashSet3 that extends HashSet while implementing IFoo.

Comment 7 Satyam Kandula 2010-07-26 23:49:28 EDT

(In reply to comment #6)
HashSet overrides iterator() of Iterable and so as List. Hence, List.iterator() is likely  referring to HashSet.iterator(). IFoo.iterator is having it's own iterator() and hence not referring to the same one.

Comment 8 Eric Jain 2010-07-27 01:16:54 EDT

I can appreciate that matching List.iterator() as a potential match for HashSet.iterator() is simpler than matching IFoo.iterator(). However, in terms of finding potential references to HashSet.iterator(), I don't see how the two are different: isn't it the exact same method that ends up being called?

Regardless, is there an option to have HashSet.iterator() match Set.iterator() but not List.iterator()? Throwing in Iterable.iterator() matches may be useful in some cases, but might widen the result set too much in other situations.

Comment 9 Satyam Kandula 2010-07-27 02:29:51 EDT

(In reply to comment #8)
I understand what you are getting at. Let me see what I can do. Currently, you cannot even filter one type and get the other. I will look into it and update accordingly.

Comment 10 David I 2011-11-02 10:19:17 EDT

Another example that is similar to this is to search for a toString() method on one of your own classes. The Filter for "References to Overridden" seems to work for me in this case.

Comment 11 Eclipse Genie 2020-02-24 04:15:04 EST

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.