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

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

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/

"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