Hi Matthew and Wes,
I haven’t worked as much with the
messages as you have, but I do wonder how much opportunity there is to localize
the protocols for state checking, perhaps within key classes (e.g., governing
state invariants around the type map or handling of I/O errors). I.e., I think
message handling is a modular implementation but it has some redundancy in the
protocol of use. It does seem to me that some of them do arise from common
policies that might well be worth teasing out. Now clearly there
shouldn’t be a single global aspect that would identify messages. But I
find myself suspecting that some of the 350 If some of the messages
don’t occur at natural AspectJ join points, it might be useful to do some
refactoring to expose the underlying commonality. The other interesting aspect
of this is the means to map different cases of the same type of error to
different messages (e.g., errors reading different kinds of path entries). However,
when the project is ready to use AspectJ for implementation of the weaver, I
think working carefully through some of these cases will be quite profitable.
Wes, I certainly agree that there’s
a lot of value in redoing designs from the start with aspects, although I think
refactoring to move to using aspects incrementally is also a viable strategy.
Ron
From:
aspectj-dev-bounces@xxxxxxxxxxx [mailto:aspectj-dev-bounces@xxxxxxxxxxx] On Behalf Of Matthew Webster
Sent: Wednesday, July 19, 2006
1:26 AM
To: AspectJ
developer discussions
Subject: RE: [aspectj-dev] Using
AspectJ to implement AspectJ
Ron and Wes,
The terms
tracing, logging and messaging mean different things to different people so I
will define how I use them WRT the compiler and AOP opportunities:
-
Tracing: objectively recording method entry/exit
with dynamic context, the primary subject of https://bugs.eclipse.org/bugs/show_bug.cgi?id=150487,
usually an ideal candidate for implementation with AOP, primarily used by
developer rather than user.
-
Error logging: objectively record exception
conditions, similar or possibly stronger case to tracing.
-
Messages: subjectively record a compiler event, not
a candidate for AOP because messages are not typically issued at well defined
AspectJ join points nor is the context consistent, calls are fare less numerous
than tracing or logging and the presence of the calls actually helps the
developer, primarily used by user.
My
only plans to unite tracing/logging and messaging is through a MessageHandler
that would allow all output from the compiler to be directed to a single,
externally configurable destination e.g. JDK 1.4 logging.
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]
"Wes"
<wes@xxxxxxxxxxxxxx>
Sent
by: aspectj-dev-bounces@xxxxxxxxxxx
18/07/2006
20:51
Please respond
to
wes@xxxxxxxxxxxxxx; Please respond to
AspectJ developer discussions <aspectj-dev@xxxxxxxxxxx>
|
|
To
|
"AspectJ developer
discussions" <aspectj-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [aspectj-dev] Using AspectJ to implement AspectJ
|
|
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 _______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev