Re: [aspectj-dev] Using AspectJ to implement AspectJ

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

The value of using of AOP and AspectJ
must always be evaluated on a case by case basis. Some of the compelling
reasons for using a tracing aspect do not apply to the AspectJ project
(at the moment): we don't have a large project team of mixed ability; we
don't have a lot of tracing code. Additionally some of the options available
to our users are not available to us: we can't use LTW for obvious reasons
and our build system does not (yet) support binary weaving. At this time
the cost of using AspectJ in terms incremental performance and/or required
build changes outweigh those associated with a (very small) hand-coded
tracing implementation. Having a more serviceable deliverable is more important
right now than exploiting AOP.

As I said in the bug report we should
be eating our own cooking (and we are in certain places already especially
AJDT), the AspectJ compiler would be a good showcase for the technology
and if we experience problems with the performance and reliability of the
tools then we will be feeling our user's pain. I think in the near future
we will start to use AspectJ more in the implementation of the compiler
but only after we have looked at other issues such as memory footprint
(Bug 146781 "Fast pipelining compilation system when only using dynamic
crosscutting") and project structure (Bug 113948 "Repackage AspectJ").
Implementing these enhancements will help us solve the tools problems and
bring us closer to using AspectJ.

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal) 
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/