On Sep 3, 2008, at 10:40 PM, Andy Clement wrote:
Hi Alex,
It is not an optimization, it is done deliberately - like avoiding
advising synthetic entities. A bridge method only ever calls a real
method - how are you losing slots? Bridge methods are only there to
cope with erasure. Should the tool that is losing slots not
recognize and ignore bridge methods ? I presume it ignores other
types of synthetic method that we do not advise like accessor
methods for inner classes?
Hi Andy,
Our tool is aimed to support full bytecode instrumentation
coverage, including JDK and synthetic methods.. In fact, we use
AspectJ as a blackbox, but we control which classes to instrument.
http://www.inf.unisi.ch/faculty/binder/documents/pppj08.pdf
I think advising bridge methods would get confusing - beyond just
advising the execution pointcut we'd probably have to go the whole
way and expose the entire method body to matching, introducing new
join points that have no equivalent in the source code and users
would wonder where on earth they came from. The method that is
delegated to from the bridge method would be a new call join point,
for example.
I would need a very compelling use case to support weaving these
methods. I guess I don't know enough about your tool at the moment...
I agree that for the normal user it can be confusing to advice
synthetic methods, but we use our tool to automate calling context
analysis... Thus, the invocation of the non advised bridge method
introduces a problem. . because our tool was able to instrument the
bridge method (pre-process), but ajc was not, so slots are lost... We
spent several hours to find this situation.. we found this problem
with a JDK classes so very hard to debug :-( and we do not have a
workaround to easily detect such situations... An option to enable
bridge methods to be advised would greatly help. ;-)
Many thanks,
Alex
Andy.
2008/9/3 Alex Villazon <[EMAIL PROTECTED]>
Thanks Andy for the rapid answer.
If I understood well, AspectJ does not advise bridge method as
optimization...
The problem is that we need to advice all methods (from third
party compiled code)... which is important for context sensitive
applications. Currently we have 'lost slots' because of the non
advised bridge methods, which are very hard to debug :-(
I'm not sure if enabling advise of bridge methods could benefit
other users.... but it would be helpful to have such a feature.
Cheers,
Alex
cheers,
Andy.
2008/9/3 Alex Villazon <[EMAIL PROTECTED]>
Dear all,
I have a problem with the following aspect which can advice
methods, depending on how it's compiled...
public class A implements java.util.Comparator <String> {
public int compare(String a, String b) {
return 0;
}
}
javac generated a compare(Object, Object) method corresponding to
public int compare(Object a, Object b) {
return compare((String)a, (String)b);
}
When weaving A.java with the following aspect, only the
compare(String, String) method is adviced...
public aspect Foo {
before() : execution(* *(..)) && !within(Foo) {}
}
javac A.java
jar cvf a.jar A.class
ajc -showWeaveInfo -inpath a.jar -outjar woven.jar Foo.aj
Join point 'method-execution(int A.compare(java.lang.String,
java.lang.String))' in Type 'A' (A.java:3) advised by before advice
from 'Foo' (Foo.aj:2)
Now, if I add the compare(Object, Object) manually, the Foo aspect
advice both compare(String, String) and compare(Object, Object)
methods!!!!
public class A implements java.util.Comparator /*<String> */ {
public int compare(String a, String b) {
return 0;
}
public int compare(Object a, Object b) {
return compare((String)a, (String)b);
}
}
javac A.java
jar cvf a.jar A.class
ajc -showWeaveInfo -inpath a.jar -outjar woven.jar Foo.aj
Join point 'method-execution(int A.compare(java.lang.String,
java.lang.String))' in Type 'A' (A.java:3) advised by before advice
from 'Foo' (Foo.aj:2)
Join point 'method-execution(int A.compare(java.lang.Object,
java.lang.Object))' in Type 'A' (A.java:6) advised by before advice
from 'Foo' (Foo.aj:2)
Curiously, the bytecode for compare(Object, Object) is strictly the
same.. in both cases..
public int compare(java.lang.Object, java.lang.Object);
Signature: (Ljava/lang/Object;Ljava/lang/Object;)I
Code:
Stack=3, Locals=3, Args_size=3
0: aload_0
1: aload_1
2: checkcast #2; //class java/lang/String
5: aload_2
6: checkcast #2; //class java/lang/String
9: invokevirtual #3; //Method compare:(Ljava/lang/String;Ljava/
lang/String;)I
12: ireturn
LineNumberTable:
line 1: 0
Is this a bug of ajc? I tested it with 1.6.1 and 1.6.2
(development version)
Thanks a lot,
Alex
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
<ATT00001.txt>
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
<ATT00001.txt>
_______________________________________________
aspectj-users mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/aspectj-users
