[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Custom JoinPoints

Hi Matthew,


If the two static parts are considered equal in the sense that sp1.equals(sp2) then they must have equal hash codes “If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.”  See http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#hashCode()  (breaking this contract causes lots of problems, e.g., in using the java.util collections).


However, I think they shouldn’t be equal either. Consider this case:


void workMethod() {

    doWork(); for (int i=0; i<9999; i++)  doWork();



I would like to distinguish the two join point static parts and they shouldn’t equal in this respect (even though if they’re on the same line we can’t distinguish which is which, which I think is more of a limitation of the bytecode weaving strategy when we have source, that we don’t implement SourceLocation.getColumn())



From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Matthew Webster
Sent: Thursday, October 19, 2006 3:32 AM
To: wes@xxxxxxxxxxxxxx; aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Custom JoinPoints



In your example below the two invocations of go() are separate join points so have their own JoinPoint.StaticPart instance. If they are written on separate lines it becomes more obvious because their source locations will be different. The signatures for the 2 join points should be "equal()" although their hashcodes will not be the same (but could be if we used String.intern()). If you invoked "go()" in a loop then you would get the same StaticJoinPoint instance.

package ajsandbox;

public class JPSP {
   static void go() {}
   public static void main(String[] args) {

   static aspect A {
       before() : call(void JPSP.go()) {

>The solution is to permit the aspect programmer to say "I
>won't be using the join point instance any more" by setting
>the (currently local-final) variable to null; in theory, if
>that's the only use, then the context data associated with
>the join point is eligible for garbage collection.

Unfortunately this won't work because the JoinPoint instance is passed as a argument to the advice method so is on the stack and so cannot be collected. Setting a local variable to null will have no effect. You will have the same problem if you use the this(), target() or args() pointcuts.

>Currently the same join point instance is shared by multiple advice
>in different aspects.

Correct, but this would have to change and any aspect associated with a custom JoinPoint factory would get its own custom instances. How else would you support multiple custom factories?

>So it should be the case, e.g., that a
>change made by around advice to replace an argument is visible to
>less precedent advice.

Don't confuse a JointPoint instance with what it refers to i.e. this/target/args. You may have 2 separate JoinPoint instances, possibly created by different factories both referring to the same context.

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