Twitter github

Introspecting Eclipse

William Godwin once said,

The philosophy of the wisest man that ever existed, is mainly derived from the act of introspection.

On my last plane ride (after a bloody mary), I did some introspection about what I think Eclipse is missing the most. With Eclipse 4.0 in the not so distant future possibly, it’s a good time for introspection.

I tried to think back about 4-5 years ago when I started to first get into Eclipse development. What was the worst pain for me? Well, here’s a good one. One of my first Eclipse-related task was to extend a commercial IDE by adding some menu entries to an existing view and develop a new editor. Sounds easy? Well, at least not back then for me. I was scouring source code to find what the relevant “object contributions” would be along with looking for the source code of the Java editor as a staring ground. This ate up a lot of time for me and left me frustrated with Eclipse but I sort of grew accustomed to it as a normal way of development (plus, I got really familiar with the Eclipse plug-in base when time went on).

I thought to myself… well, now that I’m a seasoned Eclipse developer armed with another bloody mary and about 90 minutes until my flight lands… what can I hack up as a proof of concept to improve my workflow? Let me introduce Plug-in Spy:

What’s going on here? I simply selected a class within the Package Explorer and hit F9 to let Plug-in Spy introspect what’s going on with Eclipse at the moment. Plug-in Spy pops up and lets me know what the active part (along with the implementation class PackageExplorerPart and which plug-in it came from) and active selection. This may not look incredibly useful to a seasoned Eclipse veteran, but for newcomers who ask the question “Where can I see the source for this view or editor” (which by the way, is the #1 asked question at conferences for the PDE team).

I also did a thought experiment while in the plane when analyzing one of the Mylyn features (Report as Bug):

I thought… either Mik/Eugene/Rob must’ve scoured some Eclipse source code first to figure out what the proper way of adding this functionality would be. After they implemented it, they probably thought, “this shouldn’t of taken as long as it did.” If they were armed with good introspection tools, they would have seen that an object contribution of type LogEntry would do it:

What’s the lesson learned here? Eclipse lacks good tools for introspection (we have things like SWTSpy but that’s not enough) in my opinion. I think when we look toward the future of Eclipse, we should keep tools like this in mind. This would allow developers to focus more on their implementation instead of crawling through and learning Eclipse’s internals.

Note: The Plug-in Spy currently exists in the PDE Incubator and is not “product ready” nor are there plans currently to make it so at the moment. It’s simply a proof of concept for now to collect ideas and see what people think. My next step with the spy is to add support for getting information about menus. This will help with the eternal question of “oh my gosh, how do I contribute to this menu or toolbar.” If you’re interested in enhancements, please report them to bugzilla under the Incubators component with the [spy] header.

  • Le ScaL

    There is also the runtime spy which monitor pug-in activation, class loading, etc. as well as the resource spy. All are available on an update site on one of the core page.

  • Le ScaL

    There is also the runtime spy which monitor pug-in activation, class loading, etc. as well as the resource spy. All are available on an update site on one of the core page.

  • Ilya Shinkarenko

    I use such a (home-grown) spy for quite a long time and I believe it’s a great idea to make it a part of PDE.

    p.s. just added a bug #200570

  • Ilya Shinkarenko

    I use such a (home-grown) spy for quite a long time and I believe it’s a great idea to make it a part of PDE.p.s. just added a bug #200570

  • Gautham Pai

    Great!

    I had always visualized a Firebug like plugin for Eclipse. It would be good if we could also interact with the SWT controls – for example, change properties of widgets by just clicking on it and then changing values in the SWT spy view, reposition controls or even write small bits of code to experiment with the IDE by adding event handlers on the fly, much like we can do in Firebug.

    I know I am asking for too much, but this is how far I can stretch my imagination with the work you have done. 🙂

    Thanks,
    Gautham.

  • Gautham Pai

    Great!I had always visualized a Firebug like plugin for Eclipse. It would be good if we could also interact with the SWT controls – for example, change properties of widgets by just clicking on it and then changing values in the SWT spy view, reposition controls or even write small bits of code to experiment with the IDE by adding event handlers on the fly, much like we can do in Firebug.I know I am asking for too much, but this is how far I can stretch my imagination with the work you have done. :)Thanks,Gautham.

  • Lance Walton

    It’s excellent. Took me to the right place to find something in seconds, rather than the hours it probably would have taken without.

  • Lance Walton

    It’s excellent. Took me to the right place to find something in seconds, rather than the hours it probably would have taken without.