Wednesday, February 24, 2010

Approaches to Extending JDT

As most of you who have already read my blog know, I write a lot about extending Eclipse's Java Development Tools (JDT) for use with Java-like languages such as AspectJ and Groovy. The problem, as I've mentioned before, is that while the JDT is very good at providing tool support for Java in Eclipse, it provides no support for Java-like languages. To date, I've taken two approaches to addressing this problem. Now, there is a third approach, Object Teams, that has recently made a home at Eclipse.

JDT Weaving

With AJDT, the AspectJ development tools, I developed JDT Weaving. This approach uses Equinox Weaving to weave into the JDT plugins. Yes, we are eating our own dog food here and using AspectJ to implement AJDT. But, this approach has worked well for AJDT since AJDT only requires a small number of well-defined hooks into JDT to get its tight integration.

Feature patches

For Groovy-Eclipse, our tool support for the Groovy language, the JDT Weaving approach was not feasible since we needed a larger number of hooks into JDT. And the nature of these hooks made it difficult to use AspectJ to advise them. So, instead we are using a feature patch. This means that Groovy-Eclipse ships its own (slightly modified and heavily tested) version of the JDT core plugin. This also means that Groovy-Eclipse needs to be re-released for each new version of JDT Core (however, this turns out not to be much of a problem since our release cycle is much shorter than JDT's).

Object Teams

Now, Object Teams is a third approach, which I find very exciting (actually, this approach has been around for several years, but it has only recently moved to Object Teams is itself an Aspect-Oriented extension to Java, with a component, O/T Equinox, that provides integration with Eclipse's Equinox OSGi framework. O/T Equinox has been further adapted to provide easy extensibility to JDT. The O/T blog has a slick example of this approach. I'm looking forward to exploring this approach more.

So what?

Although it's great that we have been able to get around JDT's shortcomings and there are multiple ways of doing this, but this proliferation of approaches is a little scary. There is no guarantee that these approaches will play nicely with each other. For a while, Eclipse installs with Groovy-Eclipse would break the Scala plugin (the Scala plugin uses a variant of JDT weaving). Although this problem has now been fixed, we need to be especially careful that a similar problem does not happen in the future. Similarly, the Object Teams tool support and Groovy-Eclipse are incompatible because they both ship with feature patches for JDT Core.

Of course, the best solution would be to push our changes into JDT Core itself, we have been unsuccessful as of yet. Until then, we need open communication between all JDT hackers to make sure that we are working towards the same goal.

If you're interested in learning more or have some ideas of your own, come have a chat with me at EclispeCon.


  1. My vote would be OT. It seems as the cleanest approach to me, and extension points could easily be tested in practice before given to other projects.

    Isn't this similar to circular dependencies problem? How do we solve it? We introduce "common" project.

    IMHO OTDT, Groovy, Scala IDE and AJDT should start a new "JDT extensions project" as an incubator for future JDT extensions. They should equally participate in it.

    I have some experience with equinox aspects and
    I don't think JDT weaving approach is maintainable (at least not as OT/J).

  2. I think the only long term solution is a common JDT Extensions project, and this is something that we will talk about at this year's EclipseCon.

    As for which approach is best, I am not sure OT would be best. The OT project itself uses a JDT core patch, presumably because the locations that need to be affected are not compatible with the OT approach (this is the same reason why we did not use JDT Weaving for Groovy).

  3. Yes for the JDT Extensions project!

    To answer why OT has its own JDT core patch: (1) we didn't have OT/J when we implemented the OT/J compiler :) and (2) due to the tight integration of OT/J into Java we need such a large number of changes that refactoring to aspect would be a *big* project. For 10 other plugins adaptation with OT/Equinox satisfies all our desires - for several years now.


  4. Thanks for clearing that up, Stephan. If you were to restart the OT integration with JDT today, would you go with a feature patch, or would OT be sufficient?

    The reason why AJDT and Scala do not require a core patch is that they both had a lot of work going into the plugin, including their own builders, before starting to use JDT weaving. This means that the integration points were small and well-defined enough so that AspectJ was a reasonable way to go.