[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-dev] Using AspectJ to implement AspectJ

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