Code Recommenders, Top Eclipse Juno Feature #2

Code Recommenders, Top Eclipse Juno Feature #2

The original architects of Eclipse knew that developing a single IDE that met everybody’s needs was an impossible task.  Instead of trying to boil the ocean, the team opted for an extensible model, in which others could help contribute by writing interesting plugins.  If Eclipse could provide a solid foundation, then others could help drive innovation forward — and we all benefit.  Number 2 on my Juno Top 10 Listcode recommenders — is an example of great innovation on top of a fantastic platform.

The Code Recommenders is a plugin for the Eclipse Java Development Tools that helps manage the complexity of large APIs, by means of intelligent code completion, extended documentation, smart bug detection, and more.  The knowledge the plugin contains comes from large of amount of analysis which has been performed, and is fed back into the IDE.

Code Recommenders must first be configured with a knowledge base (Model Repository Reference).

Using this knowledge, code recommenders can take a complex content assist (like the methods available on a Button):

And display a much more civilized list, based on common usage patterns:

In addition to call recommendations, you can also see a list of methods which are frequently overridden when extending a class:

Code Recommenders can also help you learn a new API by organizing the common templates when working with a single Object. For example, here we see how SWT Buttons are offen instantiated and used:

Moving beyond single call completion, code recommenders can also help you see call chains.  As any Eclipse plugin developer knows, you often get into deep call chains trying to get the Active Window, Status Line Manager, etc…

There is also support for a powerful subword completion feature.  This means you don’t need to know the entire method (or class name) to make use of content asset:

There is also a very useful Extended Documentation view which shows information about how often certain methods are called / overridden, etc… A great resource when learning a new API.

If you are a Java developer using Eclipse, make sure you give this plugin a try when installing Juno.  A huge thank-you goes out to Marcel Bruch for this great tool!  Marcel also had some help from Cheng Chen, Doug Wightman, Johannes Lerch, Stefan Henss and Sebastian Proksch,  Thanks so much everyone!

For more Eclipse Tips and Tricks (and the annual Top 10 List), why not follow me on twitter:


  • John Connolly
    Posted at 20:56, 2012-06-26

    How did Code Recommenders source it’s common usage pattern information? Usage statistics from users or static analysis of repositories, etc? I’m curious!

  • Marcel
    Posted at 12:06, 2012-06-27


    the models Recommenders delivers at the moment are sourced from the Eclipse Juno release train repository. We are currently in discussion with a few large software repository maintainers to get more data and to increase Recommenders’ model coverage. Let’s see whether they find Recommenders interesting enough to support this.

    Usage statistics from inside the IDE are not collected yet. But we are already working on the vision of “IDE 2.0” in which users can share their knowledge how they used their APIs before with other developers. But this prototype is yet not ready to use. If you like to learn more about this, please check this blog post [1]



  • Anonymous Coward
    Posted at 12:19, 2012-07-02

    Idunno … sounds to me like a smart solution to the wrong problem. Large APIs are in themselves bad, and should therefore be avoided, or split into several smaller APIs. Using such solutions to wrong problems just helps perpetuate the wrong solutions (represented in this case by large APIs).

    Mind you, I have seen large APIs, but never seen a large API which couldn’t be decomposed into smaller APIs (except for extremely badly designed ones), just teams too lazy to refactor their code. Backwards compatibility is seldomly an issue, since you most often can easily implement facades.

    • Marcel
      Posted at 19:09, 2012-07-02

      Fair point. Well-designed APIs with no more than, say, 20 methods could be a simplification. But is having large APIs actually a bad design? Which methods of, say, JButton (which has more than 380+ methods to choose from in code completion) would you consider unnecessary? And how can we split such a huge API into a simpler API without loosing some functionality, flexibility and without increasing the complexity to learn how such a new JButton collaborates with other objects/classes?

      I think arguing that large classes are a sign of bad design falls to short in most cases.

  • srujan
    Posted at 17:19, 2012-07-03


    Thank you for posting such a good article. Can you please correct the model repository to the updated link

  • Marcel
    Posted at 18:13, 2012-07-05


    I’m not sure which trouble these URLs have caused. is a plain web page that describes which distributions and channels exists (e42/e37, dev/head/stable). Ian’s screenshost above shows the url where the recommendation models are hosted. Both are not really related to each other.

    Can you elaborate a bit which information is wrong?

  • Srujan
    Posted at 23:24, 2012-07-10

    hi Marcel,

    You are right. Sorry for that. I was pointing out the url to install the software into eclipse. I have the Model repository set up to

    Aside from that, I am not getting the code recommendation. I guess the following is the issue but I am not sure how to solve it. Can you please help.

    When you go to Code Recommenders -> Calls, clicking on any of the Jar say rt.jar, it says resolution status as “UNRESOLVED”.


    • Marcel
      Posted at 23:27, 2012-07-10

      Please read and let me know if this may describe your problem. It may also be good to post followups in the recommenders forum rather than in this blog so that others can benefit from your posts too 😉

  • eclipselover
    Posted at 15:15, 2012-07-26

    Taking up the point on large APIs from the OP, seems both OP and Marcel have a case, large APIs are unwieldy but I think the cohesiveness of the API is more meaningful benchmark rather than size- the APIs/underlying class should have a single logical responsibility per the SOLID principles.