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

["Adrian Colyer" <adrian.colyer@xxxxxxxxx>]

I've been out on vacation for a couple of weeks, so only just seen this thread. Building AspectJ with AspectJ is an important direction. We actually do more in the "shadows" module than you might realise :- I'm slowly trying to move to a model where as many as possible of the changes to the JDT compiler that we need to make are encapsulated as aspects, for the self-serving reason that this makes upgrading JDT compiler level much easier.

On a quick look through we currently have aspects in place for:

* main compilation loop adaptation (gives us a chance to extra processing at the resolve, analyse, and generate compilation steps)
* publishing of anonymous types into the weaver type map at the point their signature is determined
* key parts of the ITD implementation managing the "owningClass" and "declaringClass" fields for inter-type declared fields and methods to ensure that the JDT compiler always sees the appropriate "owner" (target type or aspect) for the task in hand
* warning on swallowed exceptions is implemented as an aspect
* parser adaptation to suppress warnings on assert and enum identifier tokens in pointcut expressions

more are steadily being added as we do more work in the shadows.

On 17/07/06, Ron Bodkin <rbodkin@xxxxxxxxxxxxxx> wrote:

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.

 

_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-dev

-- 
-- Adrian
adrian.colyer@xxxxxxxxx