Getting Changes into AspectJ

(Difference between revisions)

Revision as of 14:46, 16 April 2010

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 ( https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ ). 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 aspectj-users, aspectj-dev or aosd-discuss. 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.

- what is the use case or problem being solved? is it a common situation? - does the change fit into an aspect oriented programming language? - what is the impact on: -- other language features: is this something standalone or does it interplay with existing language features? -- 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? -- annotation style: what is the impact on annotation style syntax? -- memory: will more memory be used at compile time? will more memory be used at weave time? will more memory be used at runtime? -- fitting in with the existing ajc approach: given the architecture of ajc, is this implementable? does it require a major restructure? is it likely to complicate incremental compilation? -- tools: does the new feature affect the AJDT experience? does it require new features in AJDT? -- compatibility: is this change fully compatible with existing code? will existing code need to be recompiled? is there a migration strategy required - if so, what is it?

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.

5. 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!