Hi Ron, Matthew -
I'm all for eating your own dog food.
Just wrt error handling, as you know we have a message pattern that's
designed around compiler requirements, i.e., many messages of different types,
with different consumers, separation of formatting and logic (e.g., abort
decisions). It's been relatively easy to graft error-handling and tracing
onto this message pattern, and it is easy to wire up loggers (i.e., other sinks)
as consumers. So in that case, I believe the plumbing is well modularized
and that the message sources are also well-modularized (because that's where,
say, a particular compiler error is detected. Tracing, I agree, is
different. While it would be easy to add tracing to these sinks, but I'm
not sure it would be performant or useful, since there's no sense mixing
consumers of tracing and other messages.
The primary use by the AspectJ team of AspectJ is in developing teaching
and demonstration materials, so it's not really fair to imply that we don't use
AspectJ. I believe we have, or should have, examples of every kind of use
of AspectJ there is, so semantically I think we've covered.
Engineering-wise, it's true we don't rely on AspectJ in the configurations that
users do, but (as Matthew mentioned) for the most interesting ones (e.g., LTW,
binary weaving), we wouldn't use even if we used AspectJ in the compiler.
I've long thought that the AspectJ browser would be the first component to
use aspects. While it's nice to retrofit applications like the
compiler, the interesting stuff happens when you can start from scratch and
design in aspects. The code for the browser is out there for anyone
to rewrite and contribute back; it might be due for a refresh anyway.
Wes
------------Original Message------------
From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
To: "'AspectJ developer discussions'"
<aspectj-dev@xxxxxxxxxxx>
Date: Tue, Jul-18-2006 9:35 AM
Subject: RE: [aspectj-dev] Using AspectJ to implement AspectJ
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]
_______________________________________________
aspectj-dev mailing list aspectj-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/aspectj-dev
|