Extending JDT Part II

In my previous post, I described how we have been able to use AspectJ to make JDT more friendly to other Java-like languages such as AspectJ itself and Scala. In this post, I am going to go into a little more detail as to how this happens. This post will be brief because there's really not much more to it.

(If you are unsure about what AspectJ and aspect-oriented programming are, there are plenty of places to learn about it. For an excellent long introduction to AspectJ and aspect-oriented programming, see Ramnivas's I want my AOP, and for an excellent two paragraph introduction to AspectJ see Adrian Colyer's AOP without the buzzwords).

We've implemented the Eclipse weaving service on top of Equinox Aspects (EA). Eclipse is highly dynamic and uses different classloaders for each plugin/bundle. For this reason, regular compile-time and load-time weaving will not work. We need something that can hook into the Equinox OSGi framework and perform weaving as bundles are loaded into the framework. This is exactly how EA works: EA provides a weaving hook that inspects each bundle as it is being loaded to determine if it requires any weaving. If the bundle does, it is sent off to the AspectJ load-time weaver. Actually, it is a little more fine-grained than this since classes are only sent to the weaver as they are loaded.

The benefit of using EA is that it helps us stay robust through different Eclipse versions because we are not shipping woven code or feature patches. Currently, the Eclipse weaving service is available for Eclipse 3.4, 3.4.1, 3.4.2, and (soon to be released) 3.5M5.