Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-dev] Using AspectJ to implement AspectJ

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.

 


Back to the top