Question

Under Window > Preferences > General > Search, there is the option Ignore potential matches

What does it do? Whether I activate it or not, I never see a difference.

Is it an option that only makes sense for Java development (which I never do, but I do develop in C, Python and PHP using Eclipse)?

Answer 1

See bug 127442 for examples: depending on what you are searching (a class, a method, …), the Search engine can find instances which could match (but it cannot say for certain).

Those instances are marked “POTENTIAL_MATCH“:

A method with different number of parameters is not a potential match.

(see bug 97322 )

A potential match is a match where the resolution failed (e.g. the method binding is null).
If the user searches for “foo(String)” (without qualifying String), then “foo(java.lang.String)” and “foo(p.String)” are both exact matches.

For the .class file case, I think we can only have potential matches in the case of the missing type case (see bug 196200), i.e if the .class file was compiled and some types it references were missing.

---

A current example of potential match misbehavior is found in bug 382778:

I have a public static void method printIt(String name).
When I open its call hierarchy, some callers are missing.

I am guessing the callers are missing because java search marks them as potential instead of exact matches for the printIt(String) reference.
The following code is sometimes marked as potential, and sometimes exact:

// Listing 1
PublicInterface2 impl2 = new Impl2("Name Broken");
Static.printIt(impl2.getName());

When the search result is marked potential, the caller is missing from the printIt() call hierarchy.

PublicInterface2 is an empty public interface which extends PackageInterface2Getters.
PackageInterface2Getters is an empty default-scoped interface which extends PackageInterface1Getters.
PackageInterface1Getters is a default-scoped interface which declares String getName().

So impl2.getName() above returns a String.

There are some problems reported which I guess make the matches be marked as potential:

...
Filename : \D:\workspace\eclipse\_runtimes\jdt\call-hierarchy-bug\src\main\PublicInterface2.java
COMPILED type(s)    
2 PROBLEM(s) detected 
     - Pb(2) PackageInterface1Getters cannot be resolved to a type
     - Pb(327) The hierarchy of the type PublicInterface2 is inconsistent

Turns out that:

The compiler asks the “NameEnvironment” to get the type information of any dependent type.
Search has it’s own NameEnvironment implementation in JavaSearchNameEnvironment and it is not looking for secondary types.
This is bad and it is surprising that we haven’t run into this problem until now.