Hi There,
I wanted to raise a topic that came up in Bugzilla for wider
discussion. Matthew Webster has been adding some much needed serviceability
support into the AspectJ code base, notably a pluggable tracing facility, which
will be of real value. In the related bugzilla bug entry #150487, I suggested
that AspectJ should be used to do this. I know there is some resistance to
converting the AspectJ code base to using AspectJ, and that it currently
isn’t set up to do this. I’m not happy about the tracing code, but only
because it’s scattered. Of course that’s a strategic choice, for
the project to start adopting AOP. I’m urging the project to send the
message that AOP is worth the expense of adoption and use AspectJ to develop
itself, refactoring code like this to use aspects:
public class BcelWeaver implements IWeaver {
…
private static Trace trace =
TraceFactory.getTraceFactory().getTrace(BcelWeaver.class);
public BcelWeaver(BcelWorld world) {
super();
if (trace.isTraceEnabled()) trace.enter("<init>",this,world);
…
if (trace.isTraceEnabled()) trace.exit("<init>");
}
public ResolvedType addLibraryAspect(String aspectName) {
if (trace.isTraceEnabled()) trace.enter("addLibraryAspect",this,aspectName);
…
if (trace.isTraceEnabled()) trace.exit("addLibraryAspect",type);
return type;
} else {
// FIXME AV - better warning upon no such
aspect from aop.xml
RuntimeException
ex = new
RuntimeException("Cannot
register non aspect: " + type.getName() + " , " + aspectName);
if (trace.isTraceEnabled()) trace.exit("addLibraryAspect",ex);
throw ex;
}
}
Now that the AspectJ project is reaching the point where it
is maintaining significant crosscutting concerns in its own code base, I think
it’s really important for the project to make the shift to using AspectJ
to implement itself. As I noted in the bugzilla entry I think that any loss of
productivity resulting from worse tools support will ultimately be a gain in
functionality, by making the tools have to support larger-scale project
use…
Of course it would probably be easier to start with
incremental adoption (e.g., running with tracing using load-time weaving in
Eclipse and weaving with an aspect library in the build process). And I do know
that there’s one aspect internally used by the AspectJ shadows project (to
weave after compilation), but I think this is an opportune time to really use
AspectJ to implement itself.