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?
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...
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
