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 Eclipse.org). 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.
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.
ReplyDeleteIsn'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).
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.
ReplyDeleteAs 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).
Yes for the JDT Extensions project!
ReplyDeleteTo 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.
Stephan
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?
ReplyDeleteThe 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.