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]