Community
Participate
Working Groups
I20061219-1300 I have org.eclipse.ui.workbench.texteditor in HEAD and all required plug-ins imported as binary. If I search all references to ISaveablesLifecycleListener (either via search dialog or by selecting ISaveablesLifecycleListener and then use the context menu) search does not report the following reference in Workbench.initializeDefaultServices(): serviceLocator.registerService(ISaveablesLifecycleListener.class, new SaveablesList());
Reproduced with 3.3 M4 and also with 3.2 (this reference did not exist before...). It seems that the BinaryIndexer fails to put this reference found in Workbench.class file in index and so search does not parse corresponding source. I'll investigate...
Created attachment 56636 [details] Small JAR file to reproduce the problem Detach this JAR file and put it on a build path of a 1.4 project. Then expand this JAR under the project and try to find reference to pack.ISaveablesLifecycleListener => no reference is found.
Problem comes from the fact that T.class does not generate a direct constant field "reference" when compliance is lower than 5.0... Olivier, please update the summary, thanks
Update title
Created attachment 56641 [details] Small JAR file to reproduce the problem Previous attached JAR file was not valid, this one should be ok...
Created attachment 56642 [details] JAR file compiled using 1.5 compliance to verify that problem did not occur With this JAR file built using 1.5 compliance, reference is well found by Search Engine...
Reopen.
Created attachment 56643 [details] Proposed fix I am afraid that with this fix we can fix references to things that are not types. I'll test it more.
(In reply to comment #8) > Created an attachment (id=56643) [details] > Proposed fix > > I am afraid that with this fix we can fix references to things that are not > types. > I'll test it more. > I agree. So, I think this fix could be used only if we can clearly identify that the String tag has been used for a constant field reference...
The only way to be sure that we don't dump too many "non-type" reference would be to index the bytecodes. By this, I mean that we should index the string constant used as an argument of Class.forName. This must be (or at least is expected to be) a class name. But this might slow down the binary indexer.
I discussed about this problem with Philippe and our conclusion is that it would be too much risky and complicated changes for a small benefit. We agree that Search Engine misses a references but as it can only be in a .class file, refactoring is not concerned and so this should not have too bad consequences. Note also that it only happens when compiler source level is lower than 1.5, so we can consider it will not be a problem in the future... So, close as WONTFIX.
>Note also that it only happens when compiler source level is lower than 1.5, so >we can consider it will not be a problem in the future... Wrong. Note that most of Eclipse code base will never move to 5.0 and hence future will not be of a big help here.
