RE: [aspectj-users] Custom JoinPoints

[Matthew Webster <matthew_webster@xxxxxxxxxx>]

Ron,

There are several points here:

1. You are right about hashcode (I got
things the wrong way round) but if I remove that remark from my statement
the first sentence is correct:

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. 

2. The third sentence is a problem.
The signatures are _not_ equal eventhough I think they should be: they
look the same and they are matched by the same very specific pointcut.
I suspect we need to add some "equals()" methods to the runtime
classes.

The signatures for the 2 join points
should be "equal()". If you invoked "go()" in a loop
then you would get the same StaticJoinPoint instance.


3. The JoinPoint.StaticPart objects
are not equal and shouldn't be. However this distinction is below the level
of granularity in the AspectJ join point model _not_ a weakness in the
weaving strategy, i.e. I cannot advise one without advising both, and so
cannot be relied upon: it is an artifact of the runtime implementation.
More importantly you cannot rely on source location: an aspect should behave
the same regardless of how it was woven and line numbers can be omitted
from the byte-code ("javac -o") so it's not just the column that
can be missing.

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
http://w3.hursley.ibm.com/~websterm/

"Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
Sent by: aspectj-users-bounces@xxxxxxxxxxx

19/10/2006 16:52

Please respond to
aspectj-users@xxxxxxxxxxx

To	<aspectj-users@xxxxxxxxxxx>
cc
Subject	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
 

Wes, 

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) {
       go();
        go();
   }
   static aspect A {
       before() : call(void JPSP.go()) {
           System.out.println(thisJoinPointStaticPart.hashCode());
       }
   }
} 

>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
http://w3.hursley.ibm.com/~websterm/[1]_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users