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.