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