Aspect Oriented Programming (AOP) can be used to solve a number of today's application requirements. The Eclipse Foundation's AspectJ is a popular AOP implementation. However, it can be intimidating for beginning users to get started using the technology. In a new article Matt Chapman, AJDT Project Lead, shows how AspectJ development can be made easier using the Eclipse AspectJ Development Tools (AJDT) plugin. More information on AspectJ can be found at InfoQ's AspectJ tag.
If you're doing AspectJ development without using the Eclipse AspectJ Development Tools (AJDT)this article will show you what you're missing. Even if you have used AJDT before, you might see some features you didn't know about.
An increasing number of developers are becoming reliant on the sophisticated functionality found in modern IDEs. Whilst many of us no doubt remember programming in Emacs or Vi (and I bet some of you still do) to some developers features like content assist become indispensable -- if you can't write a modest application without an IDE you're clearly a member of this control-space generation.
Aspect-oriented programming in languages such as AspectJ offers a great deal of power and improved modularity, but without the right tools it could reduce comprehensibility. You can look at some isolated Java(tm) code and gain an understanding at some level of what it's doing, but with AspectJ there may be some advice being applied so you may not see the complete picture. With some crosscutting concerns such as tracing it may be fine to be unaware of the concern, but with security or domain-specific concerns for example they may be a central part of the application. It is therefore even more beneficial to have sophisticated IDE support for AOP compared with OOP.
Throughout this article we'll explore some of the features of AJDT to show how the tools can make you more productive and increase the benefits obtained from an AOP approach.
Crosscutting in the Editor
Let's start by looking at some Java code in a plain editor:
Now let's compare this with the Eclipse Java editor:
Apart from syntax colouring, the main difference is the markers down the left and right sides of the editor. The small bars on the right are overview markers, which indicate whereabouts in the entire source file the left hand markers occur (and they can be selected to navigate to that location). The left-hand markers are advice markers, which indicate that a particular source location is affected by before (
), after (
), or around (
) advice.
In the screenshot above we can see that two lines in the paint() method are affected by before advice. The execution of the paint() method itself is also affected by advice. The general advice marker icon (
) is used to indicate a combination of advice types affecting the same source location.
You can hover over an advice marker to see a tooltip with more information, and you can right-click on it to see an "Advised By" menu, which can be used to navigate to the advice definition. In the case of the combined marker above there are two entries in the "Advised By" menu, showing that the method is affected by both before and after advice, like this:
The AspectJ Editor
AspectJ is an extension to Java, and the convention in Eclipse is to keep pure Java code (even in AspectJ projects) in .java files, and to use the .aj extension for source which uses AspectJ-specific constructs. For example new aspects will be created in .aj files. This means that the Java editor is still, by default, used for .java files, and the AspectJ editor used for .aj files. This editor is an extension of the Java editor, so it can be used for Java code as well.
Here's an aspect open in the editor:
The AspectJ editor is designed to behave in an equivalent way for AspectJ code as the Java editor does for Java code. For instance the syntax colouring extends to AspectJ keywords such as execution, around, and proceed. Other editor operations work in the same way, such as Organize Imports, Add Import, and Format.
Control-Space to the rescue
The importance of content assist (also called code completion) was mentioned earlier. The AspectJ editor provides Java-based completions within methods defined in aspects and within advice blocks (which are syntactically similar to methods). You can for example complete against advice parameters:
Pressing Control-Space at the above location gives a list of completions including the local variable location, the advice parameters mon and ticks, the special AspectJ variables thisJointPoint and thisJointPointStaticPart, a private static field in the aspect, monitorMap, and methods inherited from Object.
Aspects can also declare fields and methods on the behalf of another class. These are known as intertype declarations and require different content assist completions:
Here the enclosing aspect is defining a method called hasListeners on behalf of the Point class. The completions offered at the given location are therefore in the context of the Point class instead of that of the defining aspect.
AJDT also contributes template proposals, so you can for example type "pc" and press control-space to insert a template for a pointcut declaration:
Attack of the red squigglies
Another invaluable feature in the Java editor is showing errors as you type with a red squiggly underline. The AspectJ editor shows the same for Java constructs in aspects and also for AspectJ-specific syntax (albeit with some limitations). Hovering over the red underline shows a tooltip with more information:
Outline view
The standard outline view in Eclipse show the structure of the current document. The structure of an aspect is similar to that of a class. The new types of nodes are aspects, pointcuts, advice, intertype declarations, and declare statements, as shown below. Variants of the icons are used to indicate visibility, and in the case of advice whether there is a dynamic test to the advice (i.e. when the exact matches cannot be determined at compile time). Aspects can also contain regular fields and methods. Like with classes, this structure is populated as you type (without requiring a save in the editor) and can also be seen by expanding source files in the package explorer.
Advice decorator
Whenever a Java element (e.g. a field or method) is shown in an Eclipse view it is accompanied by an icon to indicate which type of element it is, and also its visibility. An additional image decorator is provided by AJDT to indicate which elements are affected by advice. This takes the form of a small orange triangle to the left of the element, as shown below, where the main, foo, and bar methods are being advised.
This image decorator is used whenever Java elements are shown in Eclipse views. This includes the outline view, package explorer, and the members view from the Java Browsing perspective, plus the views provided by AJDT.
The Cross References view
We've seen how AJDT shows the crosscutting nature of AspectJ by adding editor markers and decorating advised elements. These mechanisms are designed to work with the existing views and editors in order to seamlessly provide additional information. However, they are "low bandwidth" mechanisms which don't always offer detailed enough information,such as when multiple advice blocks affect the same location, or when a overview of all the advice affecting a source file is required.
This is where the Cross References view comes in (sometimes called "X-Ref" for short). It should open automatically when you start using AJDT, or you can open it manually via Window > Show View > Other... then selecting it from the AspectJ category. You can of course arrange the views in a given perspective however you like, but as a starting point try placing the Cross References view below the Outline view. Or if you only use the quick in-place outline view, usually by pressing Control-O, you can do the same with the Cross References view from the Navigate menu or by pressing Alt-Shift-P (all the short key bindings are already taken!)
The name "Cross References" is somewhat generic, because the view is general-purpose and can be extended to show any information relating to the current element selected in the active editor. In AJDT it has been configured to show crosscutting relationships for the current element.
Let's return to an earlier example where we saw the advice markers added in the editor, for the VisualiserCanvas.java source file. These markers indicated the presence of advice, and the context menu could be used to show some more information, but this requires an extra action and is not always the full story. Here's what the cross references view shows for the paint method:
Now we can see that the paint method itself is advised by some before and after advice, and also that elements within the method are advised. The method call to Image.dispose() is advised by before advice, and also the Image constructor call is advised by some other before advice, all from the RenderingMonitorInfo aspect.
With this view incorporated into your Java perspective this detailed crosscutting information is always just a glance away. The view responds to selections in the editor and outline view, so that by default information relating to the current element is always shown. There is a button on the view's toolbar to disable this link if required. There is also a button to show the crosscutting information for the entire file instead of just the current element.
Incremental compilation
One of the greatest productivity gains from using a sophisticated IDE comes from reducing the time taken to go round the edit-compile-run-debug cycle. The incremental Java compiler in Eclipse is so good at only recompiling what it needs to based on your edit that with simple changes the compile step often happens so quickly as to be barely noticeable. The AspectJ compiler used in AJDT is based on the Eclipse Java compiler, and so too aims to be as efficient. The process is made more complex by the crosscutting nature of AspectJ, but most simple changes to both classes and aspects will still result in a fast incremental compile. Some changes, such as to pointcuts or advice which has been inlined, will require a full build.
@AspectJ
So far we've seen code style aspects where aspects are declared in .aj files using the language keywords such as aspect, pointcut and before. AspectJ also supports an annotation style of declaration, known as @AspectJ style, where regular classes and methods are used in combination with Java 5 annotations. For example instead of using the pointcut keyword a method is created with the name of the pointcut, which is then marked with an @Before annotation. The value of the annotation is a string which is the main pointcut expression.
AJDT supports this @AspectJ style. The Cross References view still shows the crosscutting relationships, and markers are still shown in editors. The Add Import operation helps with the annotations defined by AspectJ, and the show errors as you type functionality helps with the basic syntax, although this does not cover the contents of the strings used in annotations. This is one drawback with this declaration style, but at least any errors are shown with the red underline and tooltip after the source file has been saved and compiled:
Hands On
The easiest way to install AJDT into Eclipse is by defining an Update Site (via Help > Software Updates > Find and Install...). See the AJDT Download page for the appropriate update site URL. There are release builds of AJDT available for the latest Eclipse release as well as for older versions of Eclipse, and there are frequently published development builds if you want to try out the latest features or need support for the latest Eclipse milestone.
You can create a new AspectJ project using the appropriate wizard or toolbar icon, or you can convert a Java project by right-clicking the project from the package explorer view and selecting AspectJ Tools > Convert to AspectJ Project from the context menu. Creating new classes and packages etc is the same as with Java projects, and there is a New Aspect wizard for creating new aspects.
Built-in Examples
AJDT bundles several example projects for your convenience, along with a simple wizard to import them into your workspace. Many of the screenshots in this article were taken using these example projects. Simply press the New button on the toolbar, or select File > New > Other..., and then expand the AspectJ category. The available examples are split into two sub-categories. Firstly, AspectJ Examples contains the sample projects from the compiler distribution, and discussed in chapter 3 of the AspectJ Programming Guide. The second sub-category is AspectJ Plug-in Examples. This is a recent addition intended to demonstrate some ways in which aspects can be used when developing Eclipse plug-ins. As of AJDT 1.4 there is only one example in this category; more should be added in future releases. The current example, called Progress Monitor Checker, shows how aspects can be used to test whether plug-ins using Eclipse progress monitors follow the rules required by the API and described in an Eclipse Corner article.
Conclusion
In this article we've seen how the AspectJ editor provides sophisticated functionality to aid the development of aspects, and how the markers and Cross References view show detailed information and support navigation of the crosscutting structure of your application. Incremental compilation improves the efficiency of the development process and the Eclipse Java debugger can still be used as the AspectJ compiler produces regular bytecodes (to set breakpoints in around advice you need to turn off inlining in the AspectJ compiler settings). AJDT also offers more advanced capabilities beyond the scope of this article including a launch configuration for load-time weaving, an aspect visualization perspective, a crosscutting comparison tool, support for developing and using aspect libraries, and functionality relating to the development of AspectJ-enabled Eclipse plug-ins.
Please visit the AJDT site to find out more,including demos, new features, downloads, and details about the AJDT newsgroup if you have any questions. AJDT is an open source Eclipse.org tools project and is released under the terms of the EPL.
About the author
Matt Chapman is a software engineer at IBM's Hursley Lab, UK. He leads the AJDT project at Eclipse.org, which develops an integrated development environment to enable developers to get the maximum benefit from AOP. He regularly presents at conferences such as EclipseCon and AOSD.
Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Copyright © 2006 International Business Machines Corp.