Bugzilla – Full Text Bug Listing
| Summary: | [search] Binary java method model elements returned by SearchEngine have unresolved parameter types | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Brian de Alwis <bsd> | ||||||
| Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | ||||||||
| Version: | 3.1 | ||||||||
| Target Milestone: | 3.2 M4 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux-GTK | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 31266 [details]
Plugin demonstrating problem
A simple plug-in for Eclipse R3.1 that displays the results of SearchEngine.searchDeclarationsOfSentMessages() for org.eclipse.jdt.ui.JavaElementLabelProvider. Note that methods with non-primitive argument types (e.g., Object) do not get proper images.
Thanks for the plugin which easily demonstrates the problem. The origin of this issue is in the way MethodLocator create handle for method while reporting declaration match (see method MethodLocator.reportDeclaration(...)). On binary type, current implementation is not enough detailed and missed the correct IMethod. It should be implemented in a similar way as it is done in MatchLocator.createHandle(AbstractMethodDeclaration,IJavaElement)... Created attachment 31319 [details]
Patch to fix this issue
This is a specific eclipse patch format including 2 projects:
- org.eclipse.jdt.core
- org.eclipse.jdt.core.tests.model
Patch released in HEAD. Test case added in JavaSearchBugsTests Verified for 3.2 M4 using build I20051213-0010 |
I'm creating a plugin for Eclipse R3.1 that makes hundreds of Java queries (using the JDT SearchEngine service) and caches the results. I often get JavaModelExceptions like the following: !ENTRY ca.ubc.cs.ariadne 4 400 2005-11-29 16:16:49.21 !MESSAGE Unexpected exception during plugin execution !STACK 1 Java Model Exception: Java Model Status [append(String) {key=Ljava/lang/StringBuffer;.append(Ljava/lang/String;)Ljava/lang/StringBuffer;} [in StringBuffer [in StringBuffer.class [in java.lang [in /.autofs/binaries/cspubliclib/pkg/jdk-1.5.0_03/jre/lib/rt.jar [in org.eclipse.draw2d]]]]] does not exist] at org.eclipse.jdt.internal.core.JavaElement.newNotPresentException(JavaElement.java:468) at org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(JavaElement.java:499) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:232) at org.eclipse.jdt.internal.core.JavaElement.getElementInfo(JavaElement.java:218) at org.eclipse.jdt.internal.core.BinaryMethod.getFlags(BinaryMethod.java:131) at ca.ubc.cs.ariadne.jdt.attributes.MemberAbstractProvider.getValue(MemberAbstractProvider.java:23) at ca.ubc.cs.ariadne.jdt.attributes.AbstractAttributeProvider.getAttribute(AbstractAttributeProvider.java:27) This happens for several classes/methods. The only commonality I've noticed is that they are all from jar files (either the JRE as above, or Eclipse .jar files). These elements all actually exist (it would be weird for StringBuffer.append() to not exist :-), though they answer exists() == false. All of these IJavaElements result from queries against the SearchEngine. In poking at this further, it appears that the IJavaElements being spoofed up by the SearchEngine doesn't have resolved parameter type names, whereas the elements in the JavaModelCache do. As BinaryMethod.hashCode() uses the parameterTypes to generate the hashCode(), this difference in name resolution causes a mismatch in the generated hashCode()s, and the element info is never found. I've attached a plugin that demonstrates the problem by using the results of SearchEngine.searchDeclarationsOfSentMessages(). This illustrates the problem on 3.1 (interestingly, this doesn't work under 3.2M3 as SE.sDOSM() returns nothing): 1. Ensure org.eclipse.jdt.* are added to your search path. 2. Open the view named BugExample (in SampleCategory) and you'll see a list of methods -- these are the result of the SearchEngine.searchDeclarationsOfSentMessages() for JavaElementLabelProvider. Notice that the methods with non-primitive arguments cannot have their images determined. If you place a breakpoint at Searcher.getMethodsSent(...), you'll see the elements returned have unresolved parameter names. Could the ResolvedBinaryMethod.uniqueKey not be used for generating hashCode() / testing equality?