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... cheers, Andy. 2008/9/3 Alex Villazon <[EMAIL PROTECTED]> > > 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 > >
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
