Ron's answer is good wrt why AspectJ is considering the methods in Object
as inherited by interface types, and that having nothing to do with annotations.
(But given the !Object workaround, I wouldn't exclude them by default.)
But your code raises a question wrt type patterns using annotations.
It just seems weird to me that 'execution(* (@Annot *).*(..))' picks out
methods not declared on the annotated type, even if they are inherited,
because annotations don't work that way. Probably users should be writing
pc() && within(@Annot *)
if they mean to restrict the execution join points to the annotated types.
In more detail...
Given a type T and its supertype ST (interface or class), I understand
that type T inherits the accessible methods in ST and thus
execution(* T.stMethod(..))
matches for a method "stMethod" declared in ST (and not in T).
But the purpose of multiple signatures was to track method overriding, i.e.,
to use "execution(void ST.stMethod())" to pick out all overriding
implementations of stMethod(). (I'm less convinced the users intend
"execution(void T.*(..))" to pick out inherited methods, declared in the
supertypes of T but not in T.)
But let's say T has annotation A and ST does not, and we're matching
execution(* (@A *).stMethod(..))
It's true that T matches (@A *), but imho there is no method-execution
join point signature that matches the pointcut signature.
The signatures (ignoring modifiers) could be
void T.stMethod() // by inheritance
void ST.stMethod() // by declaration
or just
void ST.stMethod()
where T matches ST because T extends ST, but (@A *) would not match ST
even though T has annotation A, because ST does not have annotation A.
Put another way: although overriding is transitive wrt subtypes, annotations
are not. Supertypes don't have the annotations in subtypes, and only
inherited annotations are in subtypes. (As I recall, this was one of the
reasons we shied away from permitting modifiers in type patterns used in
signatures.)
So, would it make sense to restrict the set of signatures to those types
that actually declare the method, but permit any subtype to match
such signatures? That could give us the overriding behavior but not
the unintended consequences of (@A *).stMethod(..)?
One workaround for now is to use && within(@A *), which works correctly
(e.g., not picking out implementations in unannotated subtypes), but
would not work for call join points.
Wes
------------Original Message------------
From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
To: aspectj-users@xxxxxxxxxxx
Date: Mon, Aug-21-2006 12:51 PM
Subject: RE: [aspectj-users] Why is toString matched?
Hi Brian,
AspectJ appears to be considering these methods as matching because they are defined on Object. In some sense AspectJ considers that MyInterface extends Object, just as in Java you can invoke methods on Object when you have an instance of an interface, without downcasting. You can work around this behavior by excluding methods defined on Object, e.g.,
protected pointcut nonVoidMethod() :
execution(public !void (@ServiceCallback *).*(..)) && !execution(* Object.*(..));
However, I think it would be better if AspectJ didn't consider methods defined on Object as being defined on an interface unless the interface explicitly declares them. So I think this should be a bug, although maybe there's a use case for why it should match?
Here's a similar program that shows the core issue without annotations (all the methods on MyInterfaceImpl):
public interface MyInterface {
void doWork();
int getValue();
}
class MyInterfaceImpl implements MyInterface {
public void doWork() {}
public int getValue() { return 0; }
public String toString() { return "x"; }
}
aspect MatchMyInterface {
declare warning: execution(* MyInterface.*(..)): "method on my interface";
}
From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of brian.a.yoffe@xxxxxxxxxxxx
Sent: Monday, August 21, 2006 7:42 AM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] Why is toString matched?
I'm trying to create a policy that enforces the following:
Any interface that is marked with the @Callback annotation cannot have methods that are non-void.
That is:
@Callback
public interface MyInterface {
void doWork();
int getValue();
}
public class MyInterfaceImpl implements MyInterface {
void doWork() {...} // <---- just fine, as pectected
int getValue() {...} // <---- expect error here, and it is
public String toString() {...} // <---- should be just fine, but it's included in the joinpoint and thus an error
}
I've tried to accomplish this using the following joinpoint/error:
protected pointcut nonVoidMethod() :
execution(public !void (@ServiceCallback *).*(..));
declare error : nonVoidMethod() :
"Non void method.";
However, the results I get indicate that public String toString() matches this joinpoint.
In further experimentation, I redefined the interface:
@Callback
public interface MyInterface {
void doWork();
// int getValue(); note, I commented this out of the interface
}
and here's the results
public class MyInterfaceImpl implements MyInterface {
void doWork() {...} // <---- just fine, as expected
int getValue() {...} // <---- would expect the same behavior as toString exhibits. However, this is not an error anymore
public String toString() {...} // <---- still an error
}
I am a bit lost - why is the toString joinpoint included by my pointcut? How do I prevent it?
Thanks,
Brian Yoffe
This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.
This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
