AOP@Work: New AJDT releases ease AOP development

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Intermediate

Matt Chapman (mchapman@uk.ibm.com), AJDT project leader, IBM

09 Aug 2005

AJDT Eclipse technology project leader Matt Chapman walks you through AJDT 1.2 and 1.3, the latest releases of the AspectJ development tools for Eclipse 3.0 and 3.1, respectively. The major focus of these releases is to more closely integrate AspectJ with the Eclipse platform and to offer AspectJ developers more of the advanced tooling support available to Java™ developers using Eclipse.

The AspectJ Development Tools for Eclipse (AJDT) have recently undergone considerable changes, mainly to more fully integrate with the Eclipse platform. The changes also provide AspectJ developers with greater access to tooling support on the Eclipse platform. In this article, I'll introduce you to AJDT 1.2 for Eclipse 3.0, which was released in June, and AJDT 1.3 for Eclipse 3.1, which is due for release in September (early development builds are available now).

A great deal has changed since AJDT 1.1, so this article should be of interest both to developers new to AJDT, and those familiar with earlier versions. Instead of repeatedly pointing out exactly what has changed and how, I'll use this article to take a fresh look at the current AJDT functionality and approach.

Throughout the article I'll use common scenarios to explore AJDT capabilities. All of the scenarios reflect activities undertaken by typical AspectJ developers; for example, the first scenario involves creating a simple AspectJ project from scratch, something a developer just starting out with AspectJ is likely to do to familiarize himself or herself with the language and tools. More in-depth scenarios include adding aspects to existing Java projects and working with a variety of multi-project environments. I'll also discuss the specific support for new features in AspectJ 5 and walk you through the migration process from AJDT 1.1. I'll conclude the article with a brief look at the AJDT development process itself (that is, developing AJDT using AJDT!) as well as a peek at some of the changes you can anticipate in the near future.

About this series The AOP@Work series is intended for developers who have some background in aspect-oriented programming and want to expand or deepen what they know. As with most developerWorks articles, the series is highly practical: You can expect to come away from every article with new knowledge that you can put immediately to use. Each of the authors contributing to the series has been selected for his leadership or expertise in aspect-oriented programming. Many of the authors are contributors to the projects or tools covered in the series. Each article is subjected to a peer review to ensure the fairness and accuracy of the views expressed. Please contact the authors individually with comments or questions about their articles. To comment on the series as a whole, you may contact series lead Nicholas Lesiecki. See Resources for more background on AOP.

Note that AJDT 1.2 is the latest stable release for Eclipse 3.0, replacing AJDT 1.1.12, and AJDT 1.3 will be the stable release for Eclipse 3.1. Milestone and development builds of AJDT 1.2 have been made available for Eclipse 3.1 but in order to reach a stable release for Eclipse 3.1 a separate release stream was needed, hence AJDT 1.3. Except where noted, everything described in this article applies equally to both release streams. The major exception to this is in functionality specific to AspectJ 5, which generally requires Eclipse 3.1.

See Resources to download a current version of AJDT and the Eclipse platform. You will need both to follow the examples in this article.

AJDT from scratch

For a Java developer just starting out with AspectJ, writing some simple AspectJ programs is a good place to begin. You might do this by using the examples in the AspectJ programmers guide, perhaps, or one of the many excellent AspectJ books or articles available (see the Resources section). The process of creating a new AspectJ project in Eclipse is remarkably similar to that of creating a Java project: Simply select File > New > Project > AspectJ Project, or use the New AspectJ Project shortcut on the toolbar. The rest of the wizard is pretty much identical to the New Java Project wizard.

In fact, an AspectJ project is a Java project (in Eclipse terms it has a Java nature in addition to an AspectJ nature), so any tools and plug-ins that operate on Java projects will also operate on AspectJ projects). The key difference is the Eclipse builder used to compile the project: The AspectJ compiler is used instead of the JDT Java compiler. The AspectJ compiler is an extension of the JDT compiler, and is therefore fully capable of compiling Java code.

In the sections that follow, I'll show you some of the features of AJDT that come into play in a simple development scenario.

The New Aspect wizard

Given the similarity of AspectJ projects and Java projects, I don't need to explain how to create source folders, packages, and classes, or how to configure the project's classpath -- it should all be second nature to most Eclipse Java developers (see Resources for more on Eclipse). Likewise, the experience of editing classes is the same as it's always been: You can still use the Java editor and you'll find great time-saving features like content-assist, quick fixes, and organize imports are all still in place.

So let's say the next step is to create an aspect. An aspect is AspectJ's unit of modularity and has much in common with a class in the Java language. Select File > New > Other > AspectJ > Aspect or use the New Type drop-down on the toolbar to open the New Aspect wizard, which is fairly similar to the New Class wizard with just a few different options.

The AspectJ editor

After creating a new aspect, you'll see it opened in the editor (the AspectJ editor this time) and you might notice the file created has the .aj file extension, which is the designated extension for aspects in AspectJ (classes can be left in .java files). Try entering some AspectJ code in the new aspect. You should find the editor facilities fairly similar to those for Java code. Consider the following features, for example:

• The outline view populates as you type
• Syntax errors are underlined in red
• Organize imports sorts out your imported classes
• The editor supports folding
• You can reformat the file
• Content-assist via control-space is helpful in many cases

All very familiar, isn't it? A couple of things that are missing -- including quick fixes in aspects and content-assist of certain things such as pointcut names -- will be addressed by future versions of AJDT.

Saving your aspect will result in a compilation of your project (unless you have build automatically disabled, in which case you need to press the Build button, just as with a Java project). If your aspect contains advice that affects code in your project, you should see some entries appear in the Cross References view and some markers down the left side of the editor. These are two of the ways AJDT shows you the crosscutting nature of your AspectJ projects.

Crosscutting views

The Cross References view and the Outline view can be considered partners. Whereas the Outline view shows the structure of the current document, the Cross References view shows the crosscutting relationships for the current element. A useful layout is to position the Cross References view below the Outline view, as shown in Figure 1 below. If this view is not visible, you can open it by selecting Window > Show View > Other > AspectJ, or you can right-click on an element in the Outline view and select Open Cross References from the context menu.

Clicking within a method in the editor causes the Cross References view to show any crosscutting information for that method, as illustrated in Figure 1:

In this case you can see that the method is being advised by some around advice in the GetInfo aspect. You can click on that advice to navigate to it. The advice itself is then shown in the Cross References view shown in Figure 2, where you can see the relationship from the other direction:

You also have the option to not link the Cross References view with the editor. If you take this option, the Cross References view will not respond to selections in the editor and Outline view, which can be useful if you want to keep a particular list of crosscutting information visible. Another option is to show the crosscutting information for the whole of the current file, instead of just the current element.

Finally, some developers choose not to have the Outline view permanently visible, where it would take up valuable screen space. Instead, they use the Quick Outline (from the Navigate menu, or more typically by pressing Ctrl+O), which is an in-place version of the view that appears over the editor. The same functionality is available for the Cross References view. Pressing Ctrl+Alt+X (or you can configure the key binding yourself via the AJDT preferences) displays the Quick Cross References view, as shown in Figure 3. With the Quick Outline view, pressing the key binding a second time causes the view to also show inherited members. The Quick Cross References view uses a similar mechanism to switch between showing crosscutting information for the current element and for the entire file.

Markers and image decorators

If you look at the editor for some source code that is being advised, you will see marker icons down the left-hand side of the editor. These indicate the presence and type of advice, using the same icons as in the Outline and Cross References views. There are different icons to indicate before, after, and around advice. Each of these icons has two variants: with and without a small question mark. The question mark indicates that there is a runtime test to determine whether the advice applies at that location, such as when the cflow designator is used in pointcuts. The variant without a question mark is used where the match can be completely determined at compile time.

If you right-click on the markers you will see an Advised By entry on the context menu and a submenu showing the source of the advice. If you select an entry there, the editor will open to show that advice. From the advice you will see additional markers that show the crosscutting relationship from the other direction, with an Advises submenu, as shown in Figure 4. These symmetrical markers allow consistent navigation between the source and targets of advice. Similar markers and submenus are used to indicate other crosscutting information, such as inter-type declarations.

Image decorators can also be used to show crosscutting information. If you look back to the Outline view shown in Figure 1, you should see a small orange arrow to the left of three of the methods in the view. The arrow is an Eclipse image decorator for Java elements. It is used to indicate either that the given element is being affected by advice directly, or that it contains a join point that is being advised. This helpful visual cue appears just about everywhere that Java elements appear, including the Outline view, the Cross References view, and the Members view in the Java Browsing perspective.

Back to top

Converting a Java project

After gaining some experience with AspectJ and AJDT in a simple test project, a typical next step for a developer would be to take an existing Java project and try extending it with an aspect or two. For example, you might want to add enforcement aspects, such as one to check for unwanted calls to System.out.println or Exception.printStackTrace, or production aspects, such as an aspect to implement persistence, or an aspect-oriented implementation of a design pattern.

Converting a Java project to an AspectJ project is straightforward. Simply right-click on the project and select Convert to AspectJ Project. In Eclipse terms, this adds the AspectJ nature to the project and switches it to use the AspectJ compiler, just as if you had created an AspectJ project from scratch. It is worth noting that this process can be applied to any project with a Java nature, including higher level ones such as Eclipse plug-in projects. The process is also reversible, with a context menu entry to remove the AspectJ nature and switch back to the Java compiler.

Once you have an AspectJ project instead of a Java project, you might wonder what differentiates them. Initially at least the answer is "very little." You'll continue to edit your Java classes with the Java editor using the standard document outline view and all the features you've come to rely on, including quick fixes, content assist, and early error indication via red squiggly lines. Likewise, saving changes to a class will result in a fast incremental compile of the project and you'll be able to set all the same compiler options from the project properties pages. Every legal Java program is a legal AspectJ program, so your code will compile just as it always has.

In fact, the AspectJ compiler is an extension of the Eclipse Java compiler and AJDT extends the JDT tooling as consistently and transparently as possible. This is what we mean when we talk about seamless integration. It has been one of the main focus areas for AJDT 1.2/1.3, and we've made good progress (I'll point out some remaining limitations further on in the article). The goal of seamless integration is to make the first step of switching to an AspectJ project as easy as possible; thus paving the way for gaining real value from coding with aspects.

Back to top

Managing multiple projects

Building AspectJ source code requires two distinct phases; compiling the source in .java and .aj files to generate .class files, and then applying the aspects to the generated .class files. This second phase, known as weaving, is the key difference between AspectJ and Java compilers. The Java compilation process is controlled by the classpath setting, which makes types available for resolution by the compiler. The same classpath setting is used by the AspectJ compilation process and it is configured in exactly the same way in Eclipse. However, this setting is not sufficient to control both the compilation and weaving steps in all situations. This is why there are two extra settings available for AspectJ projects.

First, there is the inpath setting. Anything specified here will be made available to the weaver and so any aspects that apply will be woven in. Entries can be added to a project's inpath by right-clicking on the project, selecting Properties, then going to the AspectJ InPath section. Entries can be either JAR files or directories (class folders), such as the bin directory of another project. Anything on the inpath is sent to the project's output, after potentially being woven with aspects.

The second additional setting is the aspectpath. Whereas the inpath controls the list of things that get woven, the aspectpath controls what is woven into that list. In other words, any aspects specified on the aspectpath are made available to the weaving process, just as if they were present in source form in the project. This setting is controlled from the AspectJ Aspect Path property page and can contain either JAR files or directories.

An output JAR setting is also present in the AspectJ section of each project's property page. This setting causes the compiler to output class files directly to a JAR file, instead of to the project's output folder.

Using aspects from other projects

To see the above settings in action, consider an example workspace. There are two projects, one called MyAspects and another called WeaveMe. Both are AspectJ projects, although the second one may or may not contain any aspects of its own. The MyAspects project contains some aspects that are required in the WeaveMe project. To connect the two projects, simply right-click on the WeaveMe project, select Properties and go to the AspectJ Aspect Path section. Then, from the Libraries tab, press Add Class Folder and select the bin directory (or whatever the name of the output directory) of the MyAspects project.

Press OK to build the project with this new setting and, assuming pointcuts in the aspects match locations in the WeaveMe source code, apply the associated advice. The editor markers and Cross References view should still show the "advised by" relationships, but now the originating end of the relationship will be described as a binary aspect and you won't be able to navigate to it. This is because in general the aspect could be outside of the Eclipse workspace, such as in an external JAR file. However, at least in this case the source is in the workspace, just in a different project, so hopefully a future version of AJDT will be able to make this connection and allow navigation to the aspect in the other project.

It is important to note that types supplied via the aspectpath also need to be available at runtime. Fortunately AJDT makes this easy for you -- instead of selecting Run > Java Application, you can use the new launch configuration Run > AspectJ/Java Application. This is the same as the Java launch configuration except that it automatically adds aspectpath entries to the runtime classpath. A second, unrelated difference is that AspectJ/Java launch configurations can also locate any main methods contained within aspects.

Weaving Java projects

What if you had a project containing Java code, in either source form or in a JAR file, to which you wanted to apply aspects? If you needed to keep the aspects separate from the project you could leave it as a Java project and create an AspectJ project to do the weaving in. In this case, you would simply add an "AspectJ InPath" setting in the AspectJ project to refer to the Java code, using either the Add JARs or the Add Class Folder button.

When doing binary weaving like this you no longer have any source code markers to show where advice is having an effect. A compiler option is helpful here: From the Other tab of the AspectJ Compiler settings for the AspectJ project (or from the global preferences), select the Output weaving info messages to problems view option. Now, whenever the project is built the Problems view will show information entries to indicate which types have been woven, as shown in Figure 5:

Note that if the input was a JAR file you might want to use the Output JAR option mentioned earlier to directly generate a woven version of the original JAR file.

Developing Aspect libraries

The concept of reusable aspect libraries is a very powerful one. Let's say you have developed an aspect that you think might be applicable to other projects. You could then generalize the aspect and separate it out into its own project to form a library. Typically an aspect in a library would define the appropriate behavior, which could then be tailored to a specific purpose as required. This would most likely involve an abstract aspect with an abstract pointcut. The project using the aspect would then extend it with a pointcut defining the appropriate scope for the aspect to apply to.

If the project using the aspect library contained a concrete version of any required abstract aspects, you could link the two projects simply by adding the library project to the Projects tab from the Java Build Path properties page. As the concrete aspect is local to the project, regular classpath lookup would be sufficient to resolve the super-aspect.

Notice also that the editor markers and Cross References view show the source of the advice as the abstract super-aspect. This is correct because that's where the advice is; however in this situation the pointcut in the concrete aspect is controlling the application of advice, and it is that which is often of interest. In a future version of AJDT, a "uses pointcut" relationship could be exposed to facilitate this connection. Given the potential of reusable aspect libraries, you can expect the general support in this area to increase in later releases of AJDT.

Working with plug-in projects

The growing popularity of the Eclipse platform means that more and more developers are building plug-ins. The good news is that it's easy to use AspectJ to work with plug-ins. Simply take a plug-in project and right-click to convert it to an AspectJ project in the same way you would a Java project. You will then be prompted to add a dependency on the org.aspectj.runtime plug-in. AspectJ programs have a runtime dependency on the aspectjrt.jar file and for plug-in projects this dependency is satisfied by the small org.aspectj.runtime plug-in. After adding this dependency to your project, you can go ahead and start using aspects in the further development of your plug-in.

The limits of integration In several areas, the integration of AJDT with the rest of Eclipse is not seamless, such as in the plug-in example, where the Create Ant Build File with AspectJ Support option has been added alongside the existing Create Ant Build File option. Eclipse plug-ins should contribute additional functionality rather than replace what's there, but in this case it would have been much better if the existing functionality could have been extended to work with AspectJ projects. The user would then just see the one Create Ant Build File option for both Java and AspectJ projects and in both cases it would "just work." In cases like this the best approach is to raise enhancement requests against the base Eclipse function to make it extensible, where such a general purpose extension makes sense.

The Eclipse Plug-in Development Environment (PDE) makes it possible to generate an Ant build file (build.xml) for your plug-in project. AJDT provides a similar option for AspectJ-enabled plug-in projects. Right-click on a plugin.xml file and select PDE Tools > Create Ant Build File with AspectJ Support. The generated build.xml file will be similar to the one generated for a Java plug-in project, except that instead of using the javac Ant task to compile the source code, you'll use the iajc task provided by AspectJ instead.

Back to top

Managing large projects

You've seen how easy it is to create a simple project using AJDT on the Eclipse platform; how to migrate a Java project to AJDT; and how to manage and work between multiple projects, and project types, using AJDT. Next, I'll show you some of the AJDT features that are particularly suited to projects with a large number of source files, as well as offering some tricks of the trade along the way.

Project-level visualization

As you saw earlier, markers in the AspectJ editor and Cross References view clearly show you the nature of crosscutting on a per-file basis. What you don't get from these features alone is a good overview of how widespread the concern is -- whether it cuts across the entire project or just a couple of packages, for example. For this type of perspective, you'll use the Visualiser.

The easiest way to bring up the Visualiser is to switch to the Aspect Visualization perspective, which presents a visual representation of the selected project consisting of a column for each source file, with a height proportional to the number of lines in the source file. Stripes are then painted on the columns at the appropriate positions to represent the source locations where advice is having an effect (or potentially having an effect, in the case of an additional runtime test). The color of each stripe corresponds to the aspect containing that advice. You can see this in the screenshot in Figure 6:

As you can see, there is the main Visualiser view and a second Visualiser Menu view, which lists the aspects being displayed. You can de-select aspects from this list to remove them from the visualization. For example, you may want to remove a pervasive logging aspect that is obscuring other aspects. You can use controls on the toolbar of the Visualiser view to zoom the view in and out, to fit the contents to the view (subject to certain minimum sizes), to only show columns that are affected by advice (non-affected columns are otherwise shown in grey), and to switch the grouping level from class view to package view (where all the classes in a package are grouped into a single column). Finally, you can use a drop-down menu to access other options such as the preference page, where you can further customize the rendering. In addition to showing the effects of advice, the visualization includes the matching locations of "declare error" and "declare warning" statements. These can be toggled on or off from the Visualiser Menu toolbar. The colors used to represent the different aspects can be changed from the list and the chosen color will be remembered.

The Visualiser is designed to cope with large projects, although quite a lot of processing is required to determine the size of every class and to render the visualization. As available graphics memory is usually far more limited than general memory, the rendering process has been optimized to keep the use of graphics memory to a minimum. The columns are rendered as they are required, so scrolling the view for the first time is not usually as smooth as it is later. General memory is used to cache the image data, unless it is in short supply, in which case the image data is regenerated each time. This means that larger projects can still be shown, but with limited memory the scrolling is not as responsive.

The Visualiser supports a selection mechanism, which can be operated via the mouse or the keyboard, to select columns, classes, or stripes. Activating a selection (by double-clicking with the mouse, or pressing the spacebar) causes the corresponding item to be opened in the editor. It is also worth noting that the Visualiser is actually a completely general-purpose component that can be tailored to visualize anything, from Eclipse markers to Google search results. As well as providing custom data to the Visualiser, you can also customize the drawing style of the columns and the colors used for the stripes. See Resources for more details.

Managing change

Projects develop over time as changes are made to the code. Classes and methods are likely to be added, removed, and renamed, as the code is refactored, bugs are fixed, and new features are implemented. Managing this change with large projects can be challenging, particularly when there is a great deal of crosscutting functionality. Capturing this functionality with aspects improves the situation by collecting the relevant code together, instead of it being scattered across the codebase. Pointcuts are then used to define the join points at which advice in the aspect applies. In the face of the above changes over time, however, even this set of matching locations can change unexpectedly.

The first approach to resolving this is to develop robust pointcuts from the start. A well-built pointcut is less likely to stop matching the required locations after changes are made to the code. For example, if you're interested in calls to an update method that takes an integer as its first parameter, you might use a pointcut such as call(* update(int)). This matches calls to update methods with a single-integer parameter. But if someone later adds an extra parameter to the method, the pointcut will no longer match. If you're only interested in the first integer parameter a better pointcut would be call(* update(int,..)), because this would still match even if extra parameters were added or removed.

Even with these precautions, some types of changes can cause problems for the most robust of pointcuts; for example, in the above case the method's parameters could be changed such that the integer of interest was no longer the first parameter. Another type of change might cause a pointcut to start matching in more places than was required. For example, if you were interested in setter methods, you might apply a set* pattern in your pointcut, but the later addition of a non-setter method called setup to the code would result in an undesirable extra match by the pointcut.

The new Crosscutting Comparison functionality -- added just in time for the AJDT 1.2.1 and 1.3 releases -- was developed precisely to assist you in handling these types of changes to your code. Crosscutting Comparisons allows you to take a snapshot of the crosscutting relationships in your project and then compare the snapshot with relationships present in a later version of the project. To create a snapshot, right-click on a project and select AspectJ Tools > Save Crosscutting Map. You will then be prompted for a filename to save the relationship map into. These files have the .ajmap extension, and are stored directly in your project. For example, when you release a particular version of your project, you might save the crosscutting relationships for that release, in order to use them as a point of reference when developing the next release.

Once you have one or more crosscutting map files in your project, you can perform a comparison. You can either compare two such files with each other, or you can compare the relationships in one file against the relationships present in the current build. These two comparison options are available by selecting one or two map files in the package explorer, then right-clicking and selecting the appropriate option from the context menu. The results of the comparison are then displayed in a new view, as shown in Figure 7:

The view shows crosscutting relationships that have been added since the first map file was recorded, as well as ones that have been removed; that is, are not present in the second map file (or in the current build). You can double-click the source and target elements to open them in the editor (except for ones that no longer exist, of course). There is a filter button on the toolbar to restrict the set of relationships that are shown. The default is to only show relationships in one direction, such as "advises", instead of also "advised by". You can also click the column headers to sort the results according to that column. Finally, note that if you have selected to compare a map file with the current build, the comparison will be redone whenever a build occurs. This gives you an ongoing view of what has changed since the map file was created, which can be very useful when refactoring code in a project.

Memory usage

In general the memory usage of AspectJ projects is higher than that of Java projects in two main areas. First, it is higher in the compiler. An aspect-oriented compiler has considerably more work to do than an object-oriented compiler, because it performs a weaving process. Second, extra work is required in the development environment in order to make the crosscutting structure of your applications explicit. Whilst this overhead cannot be avoided completely, future releases of AJDT and the AspectJ compiler will focus on reducing it.

If you're working with a large project, the first step to take is usually to increase the amount of memory available to the Java process running Eclipse. You can do this by passing an argument to the Eclipse process, something like -vmargs -Xmx512m. You might also be able to close some of the projects in your workspace if you do not require all of them to be open at once. If you still find yourself running out of memory, you might be able to arrange your projects such that some of the code is compiled by the Java compiler, with the aspects applied via binary weaving or later via load-time weaving. Another option is to disable the creation of the crosscutting structure model, using the "Other" tab of the AspectJ Compiler settings, either on a per-project basis, or for the whole workspace. Doing this will save memory but should only be used as a last resort, because you will no longer see any advice markers and the Cross References and Visualiser views will not show any crosscutting information.

Back to top

New in AspectJ 5

As I noted earlier most of the functionality specific to AspectJ 5 is only available in Eclipse 3.1 because it requires Java 5 support not present in Eclipse 3.0. Therefore, unless noted otherwise, everything in this section applies only to AJDT 1.3. Last month's AOP@Work installment, "Introducing AspectJ 5" covered the new features in AspectJ 5, so only their implications for AJDT will be discussed here. Note, however, that the steps required to use Java 5 mode in your AspectJ projects is just the same as with Java projects. Select Java > Compiler and then set the compiler compliance level to 5.0. You also need to ensure the JRE system library in your project's build path is a Java 5 one and not 1.4.2 or earlier.

A few of the changes in AspectJ 5 don't require any changes to AJDT, such as semantic changes or additional API classes. Some changes, such as the new pertypewithin aspect instantiation model, only require syntax highlighting in the editor and in this case an additional check box in the New Aspect wizard. Other changes require a bit more work, as you'll soon see. Also note that in many cases the AJDT development team has implemented a minimal level of support at first, with scope for adding richer functionality later.

The addition of annotations to Java 5 and AspectJ 5 is widely known. Because AJDT extends the JDT in Eclipse, it automatically benefits from the annotation support added there. AspectJ 5 adds new pointcut designators such as @this to match based on the presence of annotations. These require syntax highlighting in the editor. A new kind of declare statement for declaring annotations on types, methods, constructors, and fields has been added. The new declare statement is supported in AJDT by adding two new crosscutting relationships, "annotates" and "annotated by," which show in the Cross References view and in the context menu for markers, just like "advises" and "advised by."

You can see a simple example of the new declare statement in Figure 8. The aspect contains a declare @method statement and an inter-type declaration. The aspect is selected, so the Cross References view shows crosscutting information for everything in the aspect. The declare @method statement is annotating three methods -- one is the inter-type declaration and the other two are directly in the Account class. The inter-type declaration is shown to be "declared on" the Account class and also "annotated by" the @method declaration. Notice also the editor marker against the @method declaration and the two-way arrow against the inter-type declaration, as it is both the source and the target of crosscutting relationships.

Another new feature of AspectJ 5 is support for an annotation-based style of aspect declaration, which is known as the "@AspectJ" style. This allows AspectJ applications to be compiled by a regular Java 5 compiler, and then later woven by the AspectJ weaver. As an example, instead of using the pointcut keyword from the regular code-style syntax, you would define a normal Java method and attach a Java 5 annotation to the method defining the pointcut. An example of this is shown in Figure 9. As you can see, AJDT still shows you the crosscutting structure of your application, regardless of the development style used.

Back to top

Migrating from AJDT 1.1

Given the extent of the changes in AJDT 1.2 and 1.3, plus a large amount of internal restructuring, it is perhaps not surprising that upgrading an Eclipse workspace formerly used with AJDT 1.1 is a fairly complex process. However the AJDT development team has smoothed out this process as much as possible by introducing a migration wizard, as shown in Figure 10. The wizard will appear the first time you run Eclipse after upgrading your version of AJDT. Before performing the upgrade you should open any projects you wish to be included in the migration process and you should also close any instances of the AspectJ editor, because the AspectJ editor has changed. (If you don't close an instance of the editor you will just get "cannot restore editor" errors, which can be safely ignored.)

The first page of the migration wizard converts the file extensions of your source files as necessary such that aspects (and any classes that contain pointcuts or inner aspects) end up in .aj files. You can exclude projects from this process if you wish. Note that there is a conversion wizard in AJDT for later conversion of file extensions as required; this is available by right-clicking on a project or on source files individually. The following page of the migration wizard covers what is a largely internal change to the Eclipse builder for AJDT. The only case where you wouldn't want to accept the defaults here is if you wanted to use a compatibility mode whereby projects can still be used as-is on AJDT 1.1. The third page is only for AspectJ-enabled plug-in projects: Instead of having a runtime dependency on the large org.aspectj.ajde plug-in, the dependency is now on the new, very small, org.aspectj.runtime plug-in. The next page undoes any global workspace settings made by AJDT 1.1, and the final page introduces the new Cross References view.

Back to top

AJDT development notes

For nearly a year now we on the AJDT project team have been using AspectJ and AJDT to develop AJDT itself. AJDT is implemented by a growing number of plug-ins that are AspectJ-enabled. While many developers have used AJDT with larger projects, at around 200,000 lines of code, AJDT makes a reasonable testcase (in addition to our numerous JUnit tests and manual test scenarios) and it means we can find and fix a number of problems before you encounter them.

Using AOP (and specifically AspectJ and AJDT) to develop and integrate AJDT with Eclipse has helped us focus our priorities on the fixes and enhancements most needed: At first our productivity was lowered by the switch-over, but now the experience is much better thanks to the improvements in AJDT and AspectJ.

The switch was worth making purely for these reasons, but of course we also expected to get some benefits from AOP at the same time! For starters we've been able to improve our ability to diagnose problems by using an aspect to catch exceptions and write appropriate entries to the Eclipse error log -- prior to this our manual exception handling was missing from about half of the places it should have been! We can also enable a monitoring aspect that populates a view to show us various performance and resource usage measurements in the Visualiser. Aspects are also used in AJDT to enforce coding standards, keep track of changes to multiple properties pages, and wrap calls using Eclipse's ISafeRunnable interface. Perhaps the best news is that all of this is just the start: In the future we expect to make aspects a more fundamental part of the design of new functionality in AJDT.

Back to top

The future of AJDT

If you're familiar with earlier versions of AJDT you'll have seen by now that much has changed in AJDT 1.2 and 1.3. Back on AJDT 1.1 the AspectJ editor was less capable and yet was used for editing both classes and aspects, and the custom outline view was less capable than the standard Java outline view. In contrast, the new AspectJ editor provides a richer experience for editing aspects, the standard Java editor is used for editing classes, and the standard outline view has been enhanced with support for aspects. This also means that the preferences wizard to make global changes to your workspace settings is no longer required.

Functionality relating to the generation of ajdoc and support for build configurations is largely unchanged, but most other areas have been improved and extended. There are new ways of showing and navigating the crosscutting structure of your programs, new support for exporting to JAR files, converting file extensions, and creating build files; plus significantly improved support for incremental compilation (such that it is now the default) and a much more flexible Visualiser that can handle larger projects. The documentation has even been overhauled to help you get the most from AJDT.

Despite all this progress there is still much to do. Firstly, there is the issue of integration with Eclipse: In the long term, a robust fully integrated AJDT requires the Java tooling in Eclipse to be more extensible than it currently is, and we hope our experiences developing AJDT can contribute in this area. Secondly, there are always more features we can develop to enhance the tooling for AspectJ. These include aspect-oriented refactorings and increased support for developing and using aspect libraries, plus developing ways of dealing with "information overload" -- such as when increased adoption of AspectJ in a project can lead to an overwhelming number of crosscutting markers. AJDT continues to be driven by user demand, so please tell us what capabilities you need and which bugs are causing you the most problems. If you'd like to get involved please go to the AJDT homepage (see Resources) and look for the links to Bugzilla, the newsgroup, the developers mailing list, and the page of to-do tasks.

Resources

• Find out more about AJDT and download the latest version from the AJDT home page.
  
  
• Read about the general-purpose Visualiser from the Visualiser home page.
  
  
• Learn more about the AspectJ language from the AspectJ home page.
  
  
• AOP@Work is a year-long series dedicated to helping you incorporate AOP into your day-to-day Java programming. Don't miss a single article in the series. See the complete series listing. Of particular relevance to this article is Adrian Colyer's installment on AspectJ 5 and Mik Kersten's installment on AOP Development environments. See also Nicholas Lesiecki's "Enhance design patterns with AspectJ".
  
  
• To learn more about the previous version of AJDT, 1.1, see the article "Develop aspect-oriented Java applications with Eclipse and AJDT" (developerWorks, September 2004).
  
  
• For an introduction to AspectJ and AOP, check out Nick Lesieki's article "Improve modularity with aspect-oriented programming" (developerWorks, January 2002).
  
  
• Eclipse AspectJ (Adrian Colyer, Andy Clement, George Harley, Matthew Webster; Addison-Wesley Professional, 2004) is a comprehensive introduction to programming with AspectJ 1.2 and AJDT 1.1.
  
  
• AspectJ in Action (Ramnivas Laddad; Manning Publications, 2003) is an excellent resource for learning aspect-oriented programming in AspectJ.
  
  
• Eclipse In Action: A Guide for Java Developers (Independent Pub Group, 2003) is a must-read for Java developers using Eclipse.
  
  
• You'll find articles about every aspect of Java programming in the developerWorks Java technology zone.
  

About the author

		Matt Chapman is a developer with the IBM aspect-oriented software development team in Hursley, England. After working on Java technology for many years, he now leads the AJDT Eclipse technology project, developing the tools and user interface experience to allow developers to get the maximum benefit from AOP. You can contact Matt at mchapman@uk.ibm.com.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Back to top