Getting Changes into AspectJ

(Difference between revisions)

Current revision

The AspectJ programming language has evolved a lot in the past few years, and tool support has improved dramatically, thanks to the generous effort of a team of mostly industrial stakeholders. These contributions have lead to a wide-spread industry adoption of the AspectJ language and to the feeling that AspectJ is now the de-facto standard for aspect-oriented programming.

AspectJ could benefit from research results

Despite the maturity of the language and tool support, AspectJ's syntax and semantics still leave room for improvements. At several conferences and workshops on Aspect-oriented Software Development, researchers have proposed useful enhancements to the syntax and/or semantics of AspectJ, many of which could be easily integrated into the official AspectJ compiler ajc. These enhancements range from simple semantic "fixes" that require no or little syntactic changes, e.g. more sensible typing rules for around advice, to larger extensions like history-based pointcuts. We believe that many of these enhancements would benefit developers at large.

In order to bridge the gap between the research community and the AspectJ community of practitioners, a lightweight process is established. The purpose of this page is to describe the process so that potential AspectJ language enhancements can be discussed in concert with both leaders of the AspectJ project, its users, and the proponents of a language change.

Getting changes into AspectJ (ajc)

The Eclipse AspectJ tools project follows the Eclipse process. The project is run transparently with all work items tracked in eclipse bugzilla (either as enhancements or bugs) and all relevant discussion held on the aspectj-users and aspectj-dev mailing list. Due to the maturity of AspectJ and the current adoption levels, getting changes into the language does require more than just a simple patch that changes functionality. The full process is as follows:

1. For a change to the language, open an enhancement request in Bugzilla. The enhancement request should use the tag '[lang]' at the start of the summary line. It doesn't have to be particularly detailed initially, but will be expected to be fleshed out as it is progressed. Effectively the enhancement request behaves as a placeholder for reference and recording discussion. This bugzilla query will show all open language related enhancements.

2. Once raised, discussion can start. If discussion is only held in the bugzilla entry then the audience will be limited. A better approach is to start a discussion on the aosd-discuss mailing list. This list targets mostly the AOSD research community. Once discussion has matured and a proposal for an actual language design has been achieved, we recommend to move the discussion to the aspectj-dev list to include the AspectJ developers.

Reference the enhancement request and provide a succinct summary of what the benefits are, with examples. This post should try and drive users to comment on the discussion, and vote on the enhancement request. Bugzilla users have a number of votes that can be assigned amongst open issues - the number of votes accumulated by an enhancement request will be a factor in looking at whether to make the change.

3. Whilst discussion is progressing, someone wishing to get their change into AspectJ is going to have to flesh out the enhancement request. The enhancement request must show that the following points have been considered. They may need assistance from existing project developers to work out some answers. If the enhancement doesn't show these points have been considered, the progress of that enhancement may be slowed.

Motivation

What is the use case or problem being solved? Is it a common situation?

Adequacy

How does the change fit into an aspect oriented programming language?

Compatibility

• Backwards compatibility: Is this change fully compatible with existing AspectJ code? Will existing AspectJ code need to be recompiled? Is there a migration strategy required - if so, what is it?
• Other language features: Is this something standalone or does it interplay with existing language features?
• Annotation style: What is the impact on annotation style syntax?

Performance concerns

What is the impact on:

• Compile-time performance: How is compile time affected? How is weaving time affected? Is there only an additional cost if using this feature?
• Runtime performance: What is the impact on the resultant woven code? Is it slower/faster?
• Memory usage Will more memory be used at compile time, weave time or runtime? If so, how much?

Tools and Implementation

• Fit with the existing ajc approach: Given the architecture of ajc, is this implementable? Does it require a major restructuring? Is it likely to complicate incremental compilation?
• Tools: Does the new feature affect the AJDT (Eclipse) experience? Does it require new features in AJDT?

The most important thing is the use case. Enhancements solving problems that users don't have are very unlikely to get in. It is fine to have a negative impact in some of these areas - for example it could slow weaving performance, but the benefit of the enhancement must be worth the cost. Recently AspectJ has had a real focus on memory usage and performance (of weaving), so negatively impacting either of those is not taken lightly.

4. The existing AspectJ/AJDT team is already very busy - if it is a killer feature with a very compelling use case, they may pick up the request and do the work to implement it. However, for many requests the creation and submission of a patch created by the raiser is the way to go. The patch should be attached to the bugzilla enhancement. The patch should implement the feature and provide testcases (both regular scenarios and error scenarios). Ideally the patch will also include necessary documentation changes.

With a compelling use case, all points above considered (with reasonable answers) and patches provided that add the functionality to ajc, the change is likely to get in!