Community
Participate
Working Groups
I20060208-0848 + latest JDT Core 1. Workspace contains: - org.eclipse.jdt.core as source - org.eclipse.jdt.apt.ui (that has org.eclipse.jdt.ui as external jar in its classpath throught the PDE container) 2. Open org.eclipse.jdt.core.CorrectionEngine 3. Select CorrectionEngine in Java editor 4. Search for references in workspace Observe: none is found 5. Open Search dialog 6. Type in 'CorrectionEngine' 7. Search for type references in workspace Observe: References are found in jdt.ui. HOWEVER only references in import statements are found.
It is a classpath problem: apt.ui has a dependency on jdt.ui but doesn't have a direct dependency on jface.text which is required to fully resolve types in jdt.ui and thus to find the references to CorrectionEngine. Search should still find potential matches in this case. However I'm not sure what the Plug-in Dependencies container should do. Shouldn't it recursively put all required plugins on the classpath of apt.ui ? Wassim what is your take on this ?
Yes, search should find potential matches and did in 3.1.2 => it's a regression :-( I'm investigating...
Definitely a side effect of fix for bug 119203 which makes Search Engine behaving badly => increase severity Another symptom of this proble was found find by David. Search for references of field fCompilationUnit in LazyJavaTypeCompletionProposal. If you only have org.eclipse.jdt.ui plugin as prerequesite (ie. not checked-out or imported with sources) then you do not find any match! Before bug 119203, you only got potential matches. Of course search engine would behave correctly if Plug-in dependencies container resolved all required plugins recursively. Wassim, I'm looking forward about your answer to Jerome's comment 1 question...
Jerome, the issue you are pointing out in comment 1 is a classic issue captured in bug 73957. In short, the compiler needs the full dependency hierarchy on the classpath to fully resolve types and references. But if we put all those JARs on the classpath, all these types would be available in the content assist and may lead to many classloading errors since the runtime classpath is only a subset of that. bug 73957 comment 24 is an interesting approach to resolve the issue. The concern now is that if we recursively put all those JARs on the development classpath to maintain a full view of the world for the compiler, the classpath of a plug-in would have to be dynamically updated by any little change in one of those downstream plug-ins that a plug-in does not directly depend on anyway.
Back to 3.1 behavior => search engine will report all potential matches. I'll reopen bug 119203 and put it as duplicate of bug 73957 as there's nothing else search engine can do without bindings... Change done in MatchLocator.process(PossibleMatch,boolean) Test case for bug 119203 changed accordingly
Frederic, you mention in bug 119203 comment 5 that class files are currently not consulted to find references. Do you think this problem could be solved by finding references in class files and not in their attached source?
I currently do not know enough ClassFile format to be able to answer your question. I'll have to check with Olivier and Philippe whether this is theoretically feasible or not and if so, what would be the cost to get it (time to implement it and performances impact)... My assumption is that there surely was a good reason not to implement it initially, so I'm a little bit pessimistic about this solution.
I filed bug 127442 for the suggestion from comment 6.
Verified for 3.2 M5 using build I20060214-0010
