I’m glad to hear there are plans to
do this. I would argue that requirements for tracing tend to expand, so it’s
a slippery slope to start scattering tracing code, and indeed there is a fair amount
of logging code (all the message handling) and error handling code that seems
well suited to modularizing with aspects. I’ll grant that using LTW to
apply aspects to AspectJ would involve some changes and complexity to isolate a
bootstrap AspectJ from a target one (with ClassLoaders or package names…),
so it’s probably not so appealing.
I agree that there is a need to prioritize,
but I think that the AspectJ project has to be committed to using AspectJ and
should be looking for effective ways to use aspects, both to eat its own
cooking as well as to show the world how project benefits from them. With AspectJ
1.5.2 I think the core code has become quite stable and the major areas to
address are resource use (memory & speed) and tools support. Focusing on some
key improvements in these areas first does make sense to me: I would argue that
having AspectJ implemented with AspectJ will ultimately be the best way to
address both of these priorities…
From:
aspectj-dev-bounces@xxxxxxxxxxx [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Matthew Webster
Sent: Tuesday, July 18, 2006 7:27
AM
To: AspectJ
developer discussions
Cc: 'AspectJ
developer discussions'; aspectj-dev-bounces@xxxxxxxxxxx
Subject: 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
http://w3.hursley.ibm.com/~websterm/[1]
