What's new in AJDT 1.4

Here are some of the more interesting or significant changes made to the AspectJ Development Tools since the 1.3 release (see the online What's new in AJDT 1.3 page for the changes in that release).

What's new in AJDT 1.4.1

AspectJ 5 This release of AJDT incorporates the AspectJ 1.5.3 release.
Refactoring participant When you rename a Java class, there is now an aspect rename participant that will search for and update references to that class from any aspects in the same project.

Rename type participant

Improved Binary Weaving support Prior to this release, if you had a project containing some aspects, and you added the output folder to the aspect path of another project, the advised locations would show as being advised by a binary aspect and navigation to the advice would not be possible. Also no "advises" relationships would be shown in the project containing the aspects, as the weaving took place in the other project. Now AJDT looks for these binary aspects in your workspace, and locates the corresponding source code. The appropriate relationships and markers can then be shown (for both the source and target of the advice) in the same way as for source weaving within a single project. This functionality works when either a class folder or a JAR file is added to the aspect path, so long as the containing project has a source folder containing the code for the relevant aspects.

Improve support for binary weaving

Improved AspectJ Build Properties The project properties pages for configuring a project's inpath, aspect path, and output jar have been organised into a single AspectJ Build page.

new AspectJ build properties page

There is an AspectJ Tools > Configure AspectJ Build Path... shortcut to this page, available by right-clicking on a project. It is also now possible to right-click on a JAR or ZIP file in a project and select to add it to the in-path or aspect path, or remove it.

Build Automation for AspectJ-enabled plug-ins AJDT now includes a replacement pdebuild-ant.jar file to enable the AspectJ compiler to be used by automated PDE builds. This can be found in the org.eclipse.ajdt.pde.build plug-in, along with a README.txt file containing more information.
Bug fixes List of bugs fixed in AJDT 1.4.1.

What's new in AJDT 1.4

New Plug-in Example A new example project has been added to demonstrate the use of aspects in Eclipse plug-in projects. The example checks for improper usage of the Eclipse IProgressMonitor interface, such as calling beginTask() twice on the same instance, or over-reporting progress across sub-monitors.

new plug-in example

Drag and Drop Aspects Moving an aspect to a new package via drag and drop now works!

animation showing drag and drop of an aspects

Eclipse Product Export Wizard There is a new export wizard called Export Eclipse product with AspectJ support. This is exactly the same as the regular version, except it handles AspectJ-enabled plug-in projects. This means the AspectJ compiler is used to build the project, and .aj files are correctly treated as source code.

Export Wizard with AspectJ support

Greater control over advice markers In AJDT you can now change the icons used for advice markers or stop advice markers being shown altogether. This is configured on a per-aspect basis and the settings are persisted so that they can be shared with a team (e.g. through CVS).

To change the image for advice markers relating to an aspect select the aspect, file or project in the Package Explorer, right-click and select AspectJ Tools > Configure Advice Markers... from the context menu. Alternatively, the same option is available by right-clicking on an existing marker in the editor margin.

You can also choose to have no image for advice markers for a particular aspect.

Screenshot showing custom advice markers

Images can be selected from a list of samples, or from .gif or .png files contained in the project. If you want to provide your own they should be 12 pixels wide and no more than 14 pixels high and ideally have a transparent background.

Integrated build configurations The process of including and excluding files used to be different between AspectJ projects and Java projects (for historical reasons). Thanks to changes in Eclipse 3.2, it has now been possible to align the two, providing a single mechanism which is compatible across both project types.

Simply select one or more files or packages in the package explorer, right-click and select entries such as Include and Exclude from the Build Path context menu. This works with both .java and .aj files, in both Java and AspectJ projects.

When converting Java projects to AspectJ projects the current state of included and excluded files is preserved. The same is true in reverse, except that .aj files are automatically excluded as otherwise the Java builder will try to compile the AspectJ-specific source code in .aj files.

AJDT still offers the additional capability of being able to preserve an include/exclude configuration in a .ajproperties file, which can then be applied later as required.

Additional Crosscutting Comparison functionality A Propagate Up toggle button has been added to the Crosscutting Comparison view. The sources and targets of relationships shown in the view can be methods, types, and also join points within methods, such as calls to other methods and catch blocks. Pressing the toggle button increases the level of granularity by replacing these sub-method elements with their enclosing method. This means that a comparison between two locations within the same method would normally show as a difference, but with the toggle selected, they would be considered the same.

The original crosscutting comparison functionality allows comparison between two projects (or more usually two versions of the same project). It is now possible to compare two elements within the same project. These elements can be either advice statements or declare error/warning statements. For example, to see whether two advice statements affect the same locations, select them both in the outline view (or package explorer) and select Comparing Crosscutting With > Each Other from the context-menu.

Screenshot showing the compare menu

The Crosscutting Comparison view will then show the differences between the locations affected. One use of this would be when refactoring a pointcut from one which lists the join points to match individually, to one which attempts to match the same join points but with a more robust property-based pointcut.

Screenshot showing the results of comparing two advice elements

You can also compare two declare error/warning statements, or compare one declare statement with an advice statement. This second combination can be particularly useful when refactoring code to use aspects. You might first use a declare warning statement to identify behaviour that is going to be handled by an aspect, such as certain calls to a method. You then write some advice to capture that policy, by advising the relevant methods. But you need to check that the advice is accurate, in that it affects the same locations identified by the declare warning. Such a comparison might look like this:

Screenshot showing the results of comparing declare warning with advice

On its own this is not that useful (particularly when the number of advised locations is large), because the declare warning targets specific method calls, but the advice targets the execution of methods, so they all appear as differences in the comparison. This is where the Propagate Up button comes in! By selecting this the granularity of comparison is raised to the level of enclosing methods. This makes the significant difference between the two elements clear:

Screenshot showing the results after propagating up to enclosing methods

This shows that the declare warning affects a method (in this case it is a method call within that method) which is not also affected by the after advice. Naturally comparisons like this are most useful with large projects, where the crosscutting is more wide-spread.

Note: We are very grateful to Charles Zhang, Irum Godil, and Arno Jacobsen of the Middleware Systems Research Group at the University of Toronto for contributing this functionality, as part of their research into "Aspect Refactoring Verification" sponsored by the IBM CAS fellowship.

Bug fixes List of bugs fixed in AJDT 1.4.