Changing the Way Developers Learn About New APIs

Code Recommenders

Jessica Thornsby
Changing-the-Way-Developers-Learn-About-New-APIs

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…

Author
Comments
comments powered by Disqus