On Sep 4, 2008, at 1:50 AM, Andy Clement wrote: Hi Alex,
Let me point you at the code, if you change it, test it and it doesn't break unexpectedly elsewhere... then we can think about a -X option.
org/aspectj/weaver/bcel/BcelClassWeaver.shouldWeaveBody(LazyMethodGen)
let me know how it goes...
Many thanks. We will also try to find a solution in our tool to keep compatibility with standard aspectj.
Cheers,
Alex cheers, Andy. 2008/9/3 Alex Villazon <alex.villazon@xxxxxxxxxxx> 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.
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 <alex.villazon@xxxxxxxxxxx> 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 <alex.villazon@xxxxxxxxxxx> 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
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
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
|
