Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » Fastest way from org.eclipse.jdt.internal.compiler.lookup.Binding to IJavaElements?
Fastest way from org.eclipse.jdt.internal.compiler.lookup.Binding to IJavaElements? [message #760614] Sat, 03 December 2011 09:01 Go to next message
Marcel Bruch is currently offline Marcel Bruch
Messages: 226
Registered: July 2009
Senior Member
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


tw: @MarcelBruch
tw: @Recommenders
Re: Fastest way from org.eclipse.jdt.internal.compiler.lookup.Binding to IJavaElements? [message #760642 is a reply to message #760614] Sat, 03 December 2011 14:25 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak Azad
Messages: 545
Registered: July 2009
Senior Member
On 12/3/2011 7:31 PM, Marcel Bruch wrote:
> Hi,
>
> I'm migrating the call chain completion to JDT 3.8 APIs. I'm struggling
> with org.eclipse.jdt.internal.compiler.lookup.Bindings.

Are you sure you want to deal with *internal* bindings ? Usually this is
not advisable to clients of JDT/Core...

The following should work for an *external* binding
http://wiki.eclipse.org/JDT/FAQ#From_an_IBinding_to_an_IJavaElement

--
Deepak Azad
http://wiki.eclipse.org/JDT/FAQ
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 Go to previous messageGo to next message
Marcel Bruch is currently offline Marcel Bruch
Messages: 226
Registered: July 2009
Senior Member
> Are you sure you want to deal with *internal* bindings ? Usually this is
> not advisable to clients of JDT/Core...

Yes, I'm sure Smile 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 Smile

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));
}


tw: @MarcelBruch
tw: @Recommenders
Re: Fastest way from org.eclipse.jdt.internal.compiler.lookup.Binding to IJavaElements? [message #760674 is a reply to message #760658] Sun, 04 December 2011 00:45 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak Azad
Messages: 545
Registered: July 2009
Senior Member
I don't think using InternalCompletionContext or
InternalExtendedCompletionContext in client code is the right thing to do.

> 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?

Using internal/non-api code in JDT/UI would, at the very least, be
frowned upon...

--
Deepak Azad
http://wiki.eclipse.org/JDT/FAQ
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 03:23 Go to previous messageGo to next message
Marcel Bruch is currently offline Marcel Bruch
Messages: 226
Registered: July 2009
Senior Member
> 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.



tw: @MarcelBruch
tw: @Recommenders
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 Go to previous message
Deepak Azad is currently offline Deepak Azad
Messages: 545
Registered: July 2009
Senior Member
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
Previous Topic:looking for tool/plugin for compare two object at runtime
Next Topic:How to specify generated getters/setters to capitalize the first letter for a variable called nType
Goto Forum:
  


Current Time: Wed Aug 20 04:54:48 EDT 2014

Powered by FUDForum. Page generated in 0.03747 seconds