Community
Participate
Working Groups
HEAD With the fix for bug 122442, search for IJavaSearchConstants.IMPLEMENTORS should now also find subclasses of the target class. This does not work for binary classes: - have xy/Test.java: package xy; public class Test extends Exception { } -> search for implementors of Exception find nothing And now comes the fun part (-: - add a space somewhere in the editor and then do the search again -> Hooray, Test is found! I guess that's because there's no index for dirty editors. - change the class declaration to look like this (this time, save the editor): public class Test extends Exception { void m() { new Exception() { /* anonymous */ }; } } -> Now, search finds both implementors (Test and the anonymous). I guess that's because the anonymous is in the index and as soon as there's an index match, the whole file is examined thoroughly.
You're right for the first point. I mean, Search engine find the implementors because it does not use indexing for working copy. For the second point (ie. anonymous) it's a little bit more complicated... Search engine find reference due to fix of bug 3442 in method notifySourceElementRequestor(TypeDeclaration, boolean, TypeDeclaration) of SourceElementParser (line 1224). In case of anonymous without superinterface, the parser sets it with expression type. This has for consequence that indexer store a key with interface flavor for Exception super type and so return Test.java as a candidate CU for the search request (note that this fix sounds really strange as it puts a class in superinterface table... It was done a long time ago on 2.0, so I have to double-check with Olivier if this was intentional or he missed this case at that time...). Looking at all code concerning implementors search request, it seems that my conclusion in bug 12442 comment 11 was wrong (again). I discovered that indexer have filters to exclude superclasses since the beginning (bug 1G5HBQA: ITPJUI:WINNT). This seems to prove that Search Engine initial design was not to report superclasses while searching for class implementors but unfortunately have some bugs in implementation which make me thought the opposite... I'll talk with Philippe and Jerome to see whether we finally decide to keep initially intended design or change it to accept to find superclasses...
Re "anonymous of a class has super interface", see also bug 86313 (type kind of anonymous can't be determined without resolving).
I think it's a good candidate for RC1
+1
Created attachment 38302 [details] Patch to implement this change Contains patch file + jar for tests.
Created attachment 38387 [details] Tests have been rewritten to match exactly the bug test case Previous tests pass but didn't match exactly the test case as the searched class were not a binary one. I've rewrite them and search implementors for a binary class both in source and binary files... Jar files are unchanged from previous patch (so it's not completely obsolete...)
Patch released in HEAD.
Verified for 3.2 RC1 using build I20060413-0010
