| Fastest way from org.eclipse.jdt.internal.compiler.lookup.Binding to IJavaElements? [message #760614] |
Sat, 03 December 2011 09:01  |
Eclipse User |
|
|
|
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 17:53  |
| Eclipse User |
|
|
|
> 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 #760690 is a reply to message #760683] |
Sun, 04 December 2011 04:45 |
| Eclipse User |
|
|
|
On 12/4/2011 1:53 PM, Marcel Bruch wrote:
>> 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.
For a patch on JDT/UI you can use anything from within JDT/UI including
SuperTypeHierarchyCache :) But using internal stuff from other
components is not a good idea as the internals may change any time
without warning.
There is always an option to request to convert internal stuff to APIs,
but I am sure that is not going to happen with internal compiler
bindings. JDT/Core will probably have to convert these compiler bindings
to external bindings.
> 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.
Sure.
--
Deepak Azad
http://wiki.eclipse.org/JDT/FAQ
|
|
|
Powered by
FUDForum. Page generated in 0.03666 seconds
Home