During a 30 minutes demo I presented him the whole collection of tools we worked on in the group - a quite compact session with lots of ideas and concepts in it. After I finished, Frank asked whether we already presented the project to the JDT team and (as I negated) just said "well I will tell Erich about it. I think he should see that." Wow. Is it actually that easy to get in contact?
Just a few days later I was introduced to Daniel Megert and Markus Keller from IBM Research Zurich, two guys who are working on Eclipse JDT from its first day (and even before :)). We arranged a meeting in Zurich last Monday where I got the opportunity to present Code Recommenders during a so called "lunch talk"... I had no idea what a lunch talk actually looks like - but hey! No worries :)
On Monday morning I arrived at IBM Rationale in Zurich downtown. I had a nice chat with Daniel and learned quite a few things what the JDT team keeps busy behind the scenes. Then at 12 o'clock everyone in the office moved out to grab some food from the surrounding restaurants and went back to the group's common room where they unpacked their lunch and started eating.
Except me. I started talking.
Okay, so that's a lunch talk: 10 people having lunch while one guy is sitting in front of the desk entertaining the audience... Well, this looks odd for moment but frankly: it was a great atmosphere! I only wonder how previous speakers managed to eat their food. I guess they didn't... :)
However, after one hour we finished the lunch talk and started a detailed discussion on how Code Recommenders uses JDT and where JDT's defensive APIs affect code recommenders performance. We identified several potential changes / extensions to JDT which I would like to summarize in this post.
More Chatty JavaCompletionContentAssistContext
So far, the java content assist context provides plug-in developers with just a small number of interesting facts:
But what to do if you need the information of which kind the receiver of a code completion event is, or which name the receiver has? In a completion event like 'b.setT' you are almost on your own to figure out information like type and name of the receiver, the exact type of completion event (CompletionOnMemberAccess, CompletionOnMessageSend...) by either parsing the source file or rerunning the completion parser as we do in Code Recommenders. Both ways are time-consuming and take between 10 to 50 ms in our cases. Fast in general but unnecessary given that JDT completion already computed (almost) all relevant information before.
During discussion we identified a set of potential changes how content assist context could be improved to help other plug-ins to leverage the analysis results of JDT and how to provide access to more structural information like variable names and types etc.
If you are interested in discussing advances to JDT JavaCompletionContentAssistContext, just add your comments to Bug 340945 - Extension Request of JavaContentAssistInvocationContext.
Fine-grained IElementChangedListener notification on content change that is not a structural change
If you ever tried to get notifications about AST changes inside a method body, you probably know that there was no way to figure out which method's body actually changed. The only information you received was "this AST has changed... somewhere." As a tool builder who relies on information in source code you now have to reanalyze the whole AST to figure out what has changed and rerun your analysis. There was no way to build something like an incremental analyzer - and thus these tools were unnecessarily slowed down. Significantly.
I'm also happy to announce that Code Recommenders Chain Completion will move to Eclipse JDT! Therefore, we'll develop a pure JDT-based implementation and contribute this engine to JDT when ready.
On Monday morning I arrived at IBM Rationale in Zurich downtown. I had a nice chat with Daniel and learned quite a few things what the JDT team keeps busy behind the scenes. Then at 12 o'clock everyone in the office moved out to grab some food from the surrounding restaurants and went back to the group's common room where they unpacked their lunch and started eating.
Except me. I started talking.
Okay, so that's a lunch talk: 10 people having lunch while one guy is sitting in front of the desk entertaining the audience... Well, this looks odd for moment but frankly: it was a great atmosphere! I only wonder how previous speakers managed to eat their food. I guess they didn't... :)
However, after one hour we finished the lunch talk and started a detailed discussion on how Code Recommenders uses JDT and where JDT's defensive APIs affect code recommenders performance. We identified several potential changes / extensions to JDT which I would like to summarize in this post.
More Chatty JavaCompletionContentAssistContext
So far, the java content assist context provides plug-in developers with just a small number of interesting facts:
- The position in text where code completion has been triggered on,
- Some completion prefix like 'setT' as in 'button.setT<^Space>',
- The expected type the proposal should return if any,
- The enclosing Java element, i.e., the method or class in which code completion was triggered.
But what to do if you need the information of which kind the receiver of a code completion event is, or which name the receiver has? In a completion event like 'b.setT' you are almost on your own to figure out information like type and name of the receiver, the exact type of completion event (CompletionOnMemberAccess, CompletionOnMessageSend...) by either parsing the source file or rerunning the completion parser as we do in Code Recommenders. Both ways are time-consuming and take between 10 to 50 ms in our cases. Fast in general but unnecessary given that JDT completion already computed (almost) all relevant information before.
During discussion we identified a set of potential changes how content assist context could be improved to help other plug-ins to leverage the analysis results of JDT and how to provide access to more structural information like variable names and types etc.
If you are interested in discussing advances to JDT JavaCompletionContentAssistContext, just add your comments to Bug 340945 - Extension Request of JavaContentAssistInvocationContext.
More flexible Content Assist Lists
Currently, JDT provides two types of content assist windows. The 'default' content assist that shows the proposals of several engines on the first ^Space cycle, followed by various content assists lists that present proposals per category one-by-one. For instance when you press ^Space twice you get to the 'Templates' proposals, pressing ^Space three times in a row you get to SWT Templates etc.
This works pretty well and is a neat way to group things if there are just a few completion engines available. But how to deal with cases where your Eclipse installation has, say, 10 different completion engines? Putting all of them on the first, default, content assist list is not necessarily the best choice - but having to press ^Space ten times in a row to get the proposals of the last category seems odd too, right?
Agreed. This scenario is a bit special to Code Recommenders because it adds five new code completion engines to Eclipse (Intelligent Call Completion, Overrides Completion, Dynamic Templates, Chain Completion, and Example Code Search). However, it shows a configuration limitation that is not necessarily required. Wouldn't it be great if you could decide completely yourself which proposals are displayed on which content assist list? Maybe by configuring something like "Show all template proposals on the second ^Space"? How do you feel about a drag'n drop UI to configure Code Completion as sketched here:
There is a feature request Bug 340876 - [preferences][content assist] Request for more flexible configuration of content assist lists on this. We'll come up with a first patch for this request - but if you are interested in discussing how to implement this feature we'd appreciate your comments!
Now, the final topic and probably the most exciting one for tool developers at Eclipse!
If you ever tried to get notifications about AST changes inside a method body, you probably know that there was no way to figure out which method's body actually changed. The only information you received was "this AST has changed... somewhere." As a tool builder who relies on information in source code you now have to reanalyze the whole AST to figure out what has changed and rerun your analysis. There was no way to build something like an incremental analyzer - and thus these tools were unnecessarily slowed down. Significantly.
With Bug 100267 - Fine-grained IElementChangedListener notification on content change that is not a structural change the world of Eclipse tool builders changes. Drastically. JDT currently considers to notify listeners about fine-grained deltas on method level! That's incredibly great since this would allow tools like Findbugs, PMD, and any other code analyzer to drastically improve their performance by only reanalyzing those parts that actually changed - or are affected by these changes.
I can't say how exciting this feature is to me. If you are interested in discussing fine-grained AST deltas and want to add your requirements - please join the discussion and vote for this bug!
Code Recommenders Contributing Back to JDT
I'm also happy to announce that Code Recommenders Chain Completion will move to Eclipse JDT! Therefore, we'll develop a pure JDT-based implementation and contribute this engine to JDT when ready.
That's thrilling for me too :)
Sum Up
It was a very exciting event being at Erich Gamma's group in Zurich and presenting Code Recommenders to JDT experts. I'm very glad and thankful for the planned support - I'm looking forward to all these improvements!
Unfortunately, most things won't happen before Eclipse 3.8. Eclipse Release cycles for such changes are unfortunately extremely long - and thus most of the changes become effective next year earliest. But that's the way it goes. Thus: If you have any comments on any of these features - tell us about them now (here or in bugzilla)!
All the best,
Marcel
Heh, it's always nice having lunch with Erich and the JDT team by lake Zurich. I'm happy to hear that Recommenders Chain Completion will be moving into JDT, it will be a bit of work but it will be nice to have everyone benefit from the innovation going on in Recommenders.
ReplyDelete