Fastest way from org.eclipse.jdt.internal.compiler.lookup.Binding to IJavaElements? [message #760614] |
Sat, 03 December 2011 14:01 |
|
Hi,
I'm migrating the call chain completion to JDT 3.8 APIs. I'm struggling with org.eclipse.jdt.internal.compiler.lookup.Bindings. Is there a simple way (utility function) that can be used to resolve an unique key to a JavaElement?
JavaCore.create does not work (not too much of a surprise)
Here is what I do/have:
final ObjectVector visibleFields = internalContext.getVisibleFields();
for (int i = visibleFields.size(); i-- > 0;) {
final FieldBinding b = (FieldBinding) visibleFields.elementAt(i);
final String key = String.valueOf(b.computeUniqueKey());
final IJavaElement field = JavaCore.create(key);
if (field instanceof IField) {
entrypoints.add(new CallChainEdge(field, EdgeType.FIELD));
}
}
Any pointer to good example code or utility functions would be great.
Thanks, Marcel
|
|
|
|
Re: Fastest way from org.eclipse.jdt.internal.compiler.lookup.Binding to IJavaElements? [message #760658 is a reply to message #760642] |
Sat, 03 December 2011 22:53 |
|
> Are you sure you want to deal with *internal* bindings ? Usually this is
> not advisable to clients of JDT/Core...
Yes, I'm sure Ayushman made methods accessible that provide access to all accessible locals, fields and methods in the current completion context. For Code Recommenders we need the information which variables are available (and their corresponding types) to make recommendations. In this case the compiler binding are sufficient.
For the JDT chain completion we need to create IJavaElements from these internal bindings because the chain algorithm will be based on the IJavaElement hierarchy.
I had a look on the current implementation of the completion context and found something that works at least for the moment. It's not extensively tested, and thus, may fail in later tests. I'm also not very happy with this code but it looks like that this will be the ugliest part of the algorithm. If there is a smarter way converting compiler bindings to IJavaElements I would be happy to hear
Thanks,
Marcel
import org.eclipse.jdt.internal.core.util.Util;
[...]
final Util.BindingsToNodesMap EmptyNodeMap = new Util.BindingsToNodesMap() {
@Override
public ASTNode get(final Binding binding) {
return null;
}
};
// compiler bindings obtained from corecontext.getAccessibleFields/methods/locaVariables
final Binding b = (Binding) elements.elementAt(i);
IJavaElement unresolvedJavaElement = null;
EdgeType edgeType = null;
if (b instanceof FieldBinding) {
unresolvedJavaElement = Util.getUnresolvedJavaElement((FieldBinding) b, null, EmptyNodeMap);
} else if (b instanceof MethodBinding) {
final MethodBinding methodBinding = (MethodBinding) b;
unresolvedJavaElement = Util.getUnresolvedJavaElement(methodBinding, null, EmptyNodeMap);
}} else if (b instanceof VariableBinding) {
// a local variable
final VariableBinding varBinding = (VariableBinding) b;
final String varName = new String(varBinding.name);
final String varType = new String(varBinding.type.signature());
final JavaElement varParent = (JavaElement) corecontext.getEnclosingElement();
unresolvedJavaElement = new LocalVariable(varParent, varName, 0, 0, 0, 0, varType, null,
varBinding.modifiers, varBinding.isParameter());
if (unresolvedJavaElement !=null) {
entrypoints.add(new CallChainEdge(unresolvedJavaElement));
}
|
|
|
|
Re: Fastest way from org.eclipse.jdt.internal.compiler.lookup.Binding to IJavaElements? [message #760683 is a reply to message #760674] |
Sun, 04 December 2011 08:23 |
|
> I don't think using InternalCompletionContext or
> InternalExtendedCompletionContext in client code is the right thing to do.
Any alternative? The student version triggered code completion, walked through all proposals made by JDT and did some fragile string parsing to find potential anchors for chain completion.
>> I'm migrating the call chain completion to JDT 3.8 APIs.
> I imagine this is for a patch for JDT/UI? Or is it a patch for JDT/Core?
I think completion engines are part of JDT/UI --> JDT/UI
> Using internal/non-api code in JDT/UI would, at the very least, be
> frowned upon...
Ok, this will be hard. We use internal APIs in several places (e.g., org.eclipse.jdt.internal.corext.util.SuperTypeHierarchyCache) to reduce the amount of our own code.
Let's do it like this:
Let me continue the rewrite. I'll push a minimal working version on an eclipse(labs) repository as soon as it's working again. I'll try to use the minimum possible internal APIs. Then, we can discuss the code and see how to change it to use public APIs.
I guess, the use of internal APIs is not only one point we will discuss. There are lots of issues regarding the graph traversal like how to deal with circles in the graph etc. I'll come up with a few examples in documentation.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03656 seconds