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:


 

9 Comments
  • John Connolly
    Reply
    Posted at 8:56 pm, June 26, 2012

    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
    Reply
    Posted at 12:06 pm, June 27, 2012

    John,

    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]

    Best,
    Marcel

    [1] http://code-recommenders.blogspot.de/2010_08_01_archive.html

  • Anonymous Coward
    Reply
    Posted at 12:19 pm, July 2, 2012

    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
      Reply
      Posted at 7:09 pm, July 2, 2012

      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
    Reply
    Posted at 5:19 pm, July 3, 2012

    Marcel,

    Thank you for posting such a good article. Can you please correct the model repository to the updated link http://www.eclipse.org/recommenders/download/

  • Marcel
    Reply
    Posted at 6:13 pm, July 5, 2012

    Srujan,

    I’m not sure which trouble these URLs have caused.

    http://www.eclipse.org/recommenders/download/ 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
    Reply
    Posted at 11:24 pm, July 10, 2012

    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 http://download.eclipse.org/recommenders/models/juno/

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

    Thanks,
    Srujan

    • Marcel
      Reply
      Posted at 11:27 pm, July 10, 2012

      Please read http://www.eclipse.org/forums/index.php/t/366941/ 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
    Reply
    Posted at 3:15 pm, July 26, 2012

    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.

Post a Comment

Comment
Name
Email
Website