Making AspectJ development easier with AJDT

Posted by Matt Chapman on Nov 21, 2006

Sections

Architecture & Design,

Development

Topics

AspectJ ,

Aspect Oriented Programming ,

Java ,

AOP ,

Eclipse ,

Methodologies ,

AJDT

Share |

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.

RelatedVendorContent

Good Relationships: The Spring Data Neo4J Guide Book

Resin 4: Elastic Cloud Scaling for Java and PHP

Troubleshoot Java/.NET performance while getting full visibility in production

Lessons from testing service-oriented architectures

Fair Trade Software Licensing - A Guide to Licensing Options for Neo4j

RELATED Research

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 As