JAXenter speaks to Code Recommenders project lead, Marcel Bruch.
Code Recommenders is a new Eclipse project that provides tools that not only automatically analyse large code repositories and integrate the extracted data into a context-sensitive IDE, but also aims to continuously improve itself through implicit and explicit knowledge of how APIs are used by the users. JAXenter spoke to project lead Marcel Bruch, to find out more about this project.
JAXenter: Can you give us an introduction to Code Recommenders?
Marcel Bruch: Code Recommenders aims to change the way developers learn about new APIs by leveraging the knowledge of those who successfully used these APIs before.
JAXenter: What does that mean exactly?
Marcel: Have you ever asked yourself how many of the proposals Eclipse code completion presents to you and how many of them you actually need for the task at hand? Let’s consider you created a SWT Text widget in your code and next trigger code completion on this newly created variable. Code Completion now would present you 164 methods you may call on this text widget. However, typically you don’t need more than 5 methods in such a situation – and Code Recommenders tells you which ones by filtering all those methods irrelevant to your current working context.
It does so by analyzing the code of existing applications that successfully used the API before (SWT in this example) and bringing back the knowledge gained during analysis into your IDE – for instance into your code completion. But there is quite a lot more that Code Recommenders does on top of filtering unlikely methods. You can check out the project proposal and vision paper of the project to learn more about the goals of Code Recommenders.
JAXenter: Code Recommenders recently announced its first releases as an Eclipse project. What functionality is included in 0.1 and 0.2?
Marcel: Version 0.1 and 0.2 bring four new code completion engines to Eclipse: The intelligent “call completion engine” that proposes only those methods to developers that are actually relevant for their task at hand. An “overrides completion engine” that shows developers which methods to override in a given subclass – and thus tells them where to plug-in their own code. A “chain completion engine” that automatically solves questions of the kind “how do I obtain an instance of this type in my code?” and last, a dynamic, example driven code templates engine á la SWT Templates that offers code templates for common objects usages often observed in example code – but not just for SWT but virtually every framework Code Recommenders analyzes.
In addition to these completion engines, next week we will ship a first prototype of our own “example code-search engine” which enables users to find example code snippets for Eclipse APIs directly from inside their IDE.
JAXenter: What steps did you take to make the code completion functionality as fast as possible, in the 0.1 release?
Marcel: We think that the code completion window is the best place to show developers how to use an API. However, this requirement puts some performance constraints on our completion engines. As a rule of thumb we decided that standard completion for intelligent call completion engine should not take more than 50 milliseconds – otherwise the developer would become annoyed and uninstall the tools rather quickly.
To achieve this goal we split the analysis and proposal computation into different phases: Analysis takes place in a separate Eclipse builder that runs in the background on every save and workspace build; proposal computation is performed whenever completion is triggered. This way we pushed computation time down to 10 to 30 milliseconds.
However, there is still a lot of room for improvement since most of the time we spent computing the information of the completion context, i.e., determine where code completion has been triggered. This is actually the same work JDT does to compute its own completions, and thus, somewhat redundant. But I’m very happy to say that the JDT team around Daniel Megert and Markus Keller support the Code Recommenders project and opened some parts of the JDT to allow us to easily hook into the existing JDT infrastructure. These changes will reduce our own computation cost to just a few milliseconds.
Also there are few more exciting improvements JDT is currently considering, one of which is more fine-grained AST deltas up to method level. This feature allows tool developers to build incremental analysis into Eclipse, and thus, enables us to further speed up Code Recommenders. We are very happy with this support. Thanks to the JDT Team!
JAXenter: What improvements are planned in the field of chain completion, in upcoming releases?
Marcel: Chain completion is actually a very interesting completion engine since this one is the only engine that doesn’t need any example code to work properly. For Code Recommenders we developed two different versions of this engine – one based on IBM WALA (the toolkit we use for our code analysis), and one based on the existing JDT infrastructure.
The JDT team showed interest in the chain completion engine and there is a chance that it will become part of Eclipse JDT in one of the upcoming versions. We will continue development of this feature, which means we’ll add support for generics, primitives and a few things more.
JAXenter: What frameworks will future versions of Code Recommenders support?
Marcel: This is currently hard to say. The plans for upcoming versions, is to support more and more Eclipse frameworks which we have data for, and then enable users to provide/share their knowledge of how they use arbitrary APIs. Because the latter heavily depends on which frameworks developers use, it will be hard to say what comes next.
However, there are also some legal aspects to consider. For instance, some licenses prohibit sharing of knowledge, GPL licensed software in the code base may prevent companies from using Code Recommenders etc. etc. This may also influence which frameworks we’ll provide models for.
We’ll see how things work out in the next months…