Description Jim Hugunin 2004-01-26 15:56:51 EST

We’d like to improve the binary compatibility for aspects.  The motivating 
example is a very large application that uses AspectJ for a global policy like 
FFDC.  We’d like to be able to change the bodies of the advice in this aspect 
to slightly alter the policy without having to change all of the code in the 
application that this aspect has been woven against.

To provide this minimum level of backwards compatibility, we should change the 
generated names for advice to be the following:

  ajc$AdviceKind$AspectName$AdviceNumberInAspect$HashOfPointcutDesignator

AdviceNumberInAspect is just a counter starting from 1 for the first piece of 
advice, 2 for the second, …

HashOfPointcutDesignator will be based on the actual PCD used textually for 
the advice, NOT following any references.  Two easy ways to compute it would 
be using Pointcut.hashCode() or using Pointcut.toString() followed by 
something like an MD5 hash.

This change will solve the specific binary compatibility problem mentioned 
above.  This doesn’t provide a complete binary compatibility story for 
AspectJ.  Ultimately that will require a spec document like chapter XXX of the 
JLS.  Many of these binary compatibility properties will not be enforceable by 
existing JVMs.  In the short-run, a separate tool should be provided that can 
detect binary incompatible changes between versions of an application and flag 
them at build time.  In the long run we’d like to see this enforcement in a 
JVM (or AspectJVM).

Tests for this feature are in bugs/binaryCompat and ajcTestsFailing.xml.

Implementation hint: 
org.aspectj.ajdt.internal.compiler.ast.AdviceDeclaration.postParse is the 
place to start.