Home » Language IDEs » Java Development Tools (JDT) » Accessing the latest jdt.core.dom.CompilationUnit from completion context
|
| Re: Accessing the latest jdt.core.dom.CompilationUnit from completion context [message #773020 is a reply to message #773016] |
Sat, 31 December 2011 07:58   |
|
I just stumbled over the reconcile operations in ICompilationUnit. Using
final CompilationUnit reconcile = jCtx.getCompilationUnit().reconcile(AST.JLS4, true, true, null, null);
seems to work (at least on my first experiments). Is this the way to go?
Will it work if auto build is turned of?
BTW: I've trouble to understand what exactly reconcile() does.
Does it internally trigger the compilation process for the given compilation unit's editor representation and broadcast this as JavaElementChanged event?
Does calling it several times in a row result in a new event every time? Or only on change?
Is this a very costly operation then (say, more than 50 ms)?
Sorry for all these questions. I may figure them out on my own. But I'm asking these questions to be sure that I don't miss an important situation.
Thanks again. Marcel
|
|
|
| Re: Accessing the latest jdt.core.dom.CompilationUnit from completion context [message #773624 is a reply to message #773020] |
Mon, 02 January 2012 05:37 |
 Jay Arthanareeswaran
Messages: 128
Registered: July 2009 |
Senior Member |
|
|
Marcel Bruch wrote on Sat, 31 December 2011 02:58I just stumbled over the reconcile operations in ICompilationUnit. Using
final CompilationUnit reconcile = jCtx.getCompilationUnit().reconcile(AST.JLS4, true, true, null, null);
seems to work (at least on my first experiments). Is this the way to go?
Will it work if auto build is turned of?
It will work. However, reconcile works only on the working copy.
Marcel Bruch wrote on Sat, 31 December 2011 02:58
BTW: I've trouble to understand what exactly reconcile() does.
Does it internally trigger the compilation process for the given compilation unit's editor representation and broadcast this as JavaElementChanged event?
Yes, it does and it makes the working copy consistent with the underlying resource, updates the Java model and if requested and notifies the java model listeners, produces AST (which is what you need) and reports problems if required. And reconcile happens even if the auto-build is turned off.
Marcel Bruch wrote on Sat, 31 December 2011 02:58
Does calling it several times in a row result in a new event every time? Or only on change?
Is this a very costly operation then (say, more than 50 ms)?
Once reconciled, the subsequent calls are no-op. So, shouldn't be a problem, really.
Marcel Bruch wrote on Sat, 31 December 2011 02:58Sorry for all these questions. I may figure them out on my own. But I'm asking these questions to be sure that I don't miss an important situation.
Thanks again. Marcel
No problem.
|
|
| |
| Re: Accessing the latest jdt.core.dom.CompilationUnit from completion context [message #775592 is a reply to message #773624] |
Fri, 06 January 2012 10:18 |
Dani Megert
Messages: 3802
Registered: July 2009 |
Senior Member |
|
|
On 02.01.2012 06:37, Jayaprakash Arthanareeswaran wrote:
> Marcel Bruch wrote on Sat, 31 December 2011 02:58
>> I just stumbled over the reconcile operations in ICompilationUnit. Using
>> final CompilationUnit reconcile =
>> jCtx.getCompilationUnit().reconcile(AST.JLS4, true, true, null, null);
>>
>> seems to work (at least on my first experiments). Is this the way to go?
>> Will it work if auto build is turned of?
>
> It will work.
Well, it depends how you define "works" ;-).
The reconciler only kicks in afer some quiet time. If your completion
proposal computer kicks in before (which is likely to happen when typing
code and using content assist) then you would either use an outdated AST
or have to wait for the AST (which would be the same as asking the
shared AST provider with the WAIT_ACTIVE_ONLY flag) or create it
yourself (could be an option if you don't need a fully resolved AST).
The general rule is not to use an AST for content assist.
Also note that the AST from the reconciler and the one used/created by
content assist aren't the same. See also https://bugs.eclipse.org/110181.
Dani
> However, reconcile works only on the working copy.
>
> Marcel Bruch wrote on Sat, 31 December 2011 02:58
>> BTW: I've trouble to understand what exactly reconcile() does.
>> Does it internally trigger the compilation process for the given
>> compilation unit's editor representation and broadcast this as
>> JavaElementChanged event?
>
> Yes, it does and it makes the working copy consistent with the
> underlying resource, updates the Java model and if requested and
> notifies the java model listeners, produces AST (which is what you
> need) and reports problems if required. And reconcile happens even if
> the auto-build is turned off.
>
> Marcel Bruch wrote on Sat, 31 December 2011 02:58
>> Does calling it several times in a row result in a new event every
>> time? Or only on change?
>>
>> Is this a very costly operation then (say, more than 50 ms)?
>
> Once reconciled, the subsequent calls are no-op. So, shouldn't be a
> problem, really.
>
> Marcel Bruch wrote on Sat, 31 December 2011 02:58
>> Sorry for all these questions. I may figure them out on my own. But
>> I'm asking these questions to be sure that I don't miss an important
>> situation.
>> Thanks again. Marcel
>
> No problem.
|
|
|
| Re: Accessing the latest jdt.core.dom.CompilationUnit from completion context [message #775659 is a reply to message #775592] |
Fri, 06 January 2012 13:25 |
Marcel Bruch
Messages: 49
Registered: July 2009 |
Member |
|
|
On 06.01.12 11:18, Daniel Megert wrote:
> On 02.01.2012 06:37, Jayaprakash Arthanareeswaran wrote:
>> Marcel Bruch wrote on Sat, 31 December 2011 02:58
>>> I just stumbled over the reconcile operations in ICompilationUnit. Using
>>> final CompilationUnit reconcile =
>>> jCtx.getCompilationUnit().reconcile(AST.JLS4, true, true, null, null);
>>>
>>> seems to work (at least on my first experiments). Is this the way to go?
>>> Will it work if auto build is turned of?
>>
>> It will work.
> Well, it depends how you define "works" ;-).
>
> The reconciler only kicks in afer some quiet time. If your completion
> proposal computer kicks in before (which is likely to happen when typing
> code and using content assist) then you would either use an outdated AST
> or have to wait for the AST (which would be the same as asking the
> shared AST provider with the WAIT_ACTIVE_ONLY flag)
does "or have to wait" mean that I'll have to wait if no ast has been
build _before_? For instance, if code completion is triggered the first
time immediately in an editor?
> or create it
> yourself (could be an option if you don't need a fully resolved AST).
I'm relying on (i) all statements and all bindings inside the enclosing
method and (ii) all declared methods and types of the compilation unit.
Will a slim parser be faster than the reconcile operation? I might be
interested in a full AST to do larger analyses. I can live with slightly
outdated ASTs (at least I think I could).
> The general rule is not to use an AST for content assist.
Any alternatives you can propose? Compiler AST? I need something that
allows me do some analysis.
> Also note that the AST from the reconciler and the one used/created by
> content assist aren't the same. See also https://bugs.eclipse.org/110181.
I'm not sure I got all details in this bug. Is it resolving the binding
for the enclosing method only?
Thanks,
Marcel
|
|
|
| Re: Accessing the latest jdt.core.dom.CompilationUnit from completion context [message #775680 is a reply to message #775659] |
Fri, 06 January 2012 14:05 |
Dani Megert
Messages: 3802
Registered: July 2009 |
Senior Member |
|
|
On 06.01.2012 14:25, Marcel Bruch wrote:
> On 06.01.12 11:18, Daniel Megert wrote:
>> On 02.01.2012 06:37, Jayaprakash Arthanareeswaran wrote:
>>> Marcel Bruch wrote on Sat, 31 December 2011 02:58
>>>> I just stumbled over the reconcile operations in ICompilationUnit.
>>>> Using
>>>> final CompilationUnit reconcile =
>>>> jCtx.getCompilationUnit().reconcile(AST.JLS4, true, true, null, null);
>>>>
>>>> seems to work (at least on my first experiments). Is this the way
>>>> to go?
>>>> Will it work if auto build is turned of?
>>>
>>> It will work.
>> Well, it depends how you define "works" ;-).
>>
>> The reconciler only kicks in afer some quiet time. If your completion
>> proposal computer kicks in before (which is likely to happen when typing
>> code and using content assist) then you would either use an outdated AST
>> or have to wait for the AST (which would be the same as asking the
>> shared AST provider with the WAIT_ACTIVE_ONLY flag)
>
> does "or have to wait" mean that I'll have to wait if no ast has been
> build _before_? For instance, if code completion is triggered the
> first time immediately in an editor?
Yes, and also if one types and quickly invokes Ctrl+Space. This might
block content assist (and hence the UI) for several seconds.
>
>> or create it
>> yourself (could be an option if you don't need a fully resolved AST).
>
> I'm relying on (i) all statements and all bindings inside the
> enclosing method and (ii) all declared methods and types of the
> compilation unit.
Oops! ;-)
>
> Will a slim parser be faster than the reconcile operation?
I guess so, because you could probably reduce the scope which you need
to scan (not sure).
> I might be interested in a full AST to do larger analyses. I can live
> with slightly outdated ASTs (at least I think I could).
If the user ends up with an unpredictable UI, I'd say "no".
>
>> The general rule is not to use an AST for content assist.
>
> Any alternatives you can propose? Compiler AST? I need something that
> allows me do some analysis.
1. Compute the requested data on a faster/smarter way.
2. Try to figure out whether JDT Core could give you the pieces you need
(but this will most likely not be the full internal AST used by content
assist).
>
>> Also note that the AST from the reconciler and the one used/created by
>> content assist aren't the same. See also
>> https://bugs.eclipse.org/110181.
>
> I'm not sure I got all details in this bug. Is it resolving the
> binding for the enclosing method only?
It returns a Java element but the internal AST would have more info AFAIK.
Dani
>
> Thanks,
> Marcel
>
|
|
| |
| Re: Accessing the latest jdt.core.dom.CompilationUnit from completion context [message #775818 is a reply to message #775753] |
Fri, 06 January 2012 18:19 |
|
Ah, well. Wouldn't call it "access" so far... The fields are protected and private:
public Optional<InternalExtendedCompletionContext> getExtendedContext() {
try {
final Field ctxField = coreContext.getClass().getDeclaredField("extendedContext");
ctxField.setAccessible(true);
final InternalExtendedCompletionContext extendedContext = cast(ctxField.get(coreContext));
final Field cuField = extendedContext.getClass().getDeclaredField("compilationUnitDeclaration");
cuField.setAccessible(true);
final CompilationUnitDeclaration cu = cast(cuField.get(extendedContext));
return fromNullable(extendedContext);
} catch (final Exception e) {
throw throwUnhandledException(e);
}
}
Anyway, this cu does not contain statements in the enclosing method. I'm currently using an ASTVisitor to collect all method calls that get executed on the variable code completion was triggered on. Without these statements it's a bit hard to make any valuable recommendations 
Is there a fast way to create a complete AST of the enclosing method?
[Updated on: Fri, 06 January 2012 18:20] Report message to a moderator |
|
|
Goto Forum:
Current Time: Thu Apr 25 09:30:22 GMT 2024
Powered by FUDForum. Page generated in 1.09473 seconds |
] 
Search
Help
Register
Login
Home
