From: Renaud P. <ren...@in...> - 2006-01-31 16:24:07
|
Hi Adrian, As I said on the Spoon-AOP page, this is on-going work and I need to=20 investigate and explain more what it does exactly. For the moment, it=20 may seem a little bit "magic" when you do not know about Spoon templates=20 and I am sorry about this. I will complete and explain better when my=20 time will allow me. However, I would like to explain myself a little bit better in this=20 email and answer some of your questions. > into spoon itself yet). Your comment on the AspectJ performance is a=20 > little misleading.=20 I am sorry about this, but it is hard to cover all the details of things=20 when you want to make a clear point. Here, the code I show gives the=20 results I put in my table. Anybody can try it and get the same results.=20 I am perfectly aware that this example is a little bit biased (like most=20 performance figures), but that's to make my point. > AspectJ will optimize any use of thisJoinPoint that=20 > uses only the "thisJoinPointStaticPart" of the JoinPoint interface.=20 > "thisJoinPoint.getArgs()" falls out of that contract, because it return= s=20 > the actual argument array. The statically knowable subset of join point= =20 > information can be no different between Spoon-AOP and AspectJ (or any=20 > other Java-based AOP implementation). Really? Well, I took this example exactly because in AspectJ, you cannot=20 access the number of parameters as static information. In Spoon-AOP you=20 can. So I can write an advice that says: if(_argumentCount_=3D=3D0) { do_0 } if(_argumentCount_=3D=3D1) { do_1 } if(_argumentCount_>=3D2) { do_gte_2 } And there will be no overhead. Even better, if the number of arguments is 1 for a given joinpoint, the=20 woven code will be exactly (partial evaluation): do_1 If you want to know all the information that Spoon-AOP can statically=20 access, you can refer to the template parameters defined in the Aspect=20 class: http://www.lifl.fr/~pawlak/spoon-aop/javadoc/spoon/aop/Aspect.html Anyway, in addition to these statically known info about the joinpoint,=20 Spoon-AOP is open by using compile-time reflection, similarly to Josh:=20 http://www.csg.is.titech.ac.jp/paper/chiba-aosd2004.pdf It means that any aspect can define new static info by introspecting a=20 Java metamodel provided by Spoon at compile time. For example, let's say=20 I want to add an information that tells me if a method uses a field f,=20 well I can do it with Spoon-AOP (and use it in my advice with no runtime=20 overhead)! >=20 > In AspectJ you can: >=20 > * implement the example much more efficiently using a pointcut: =20 > before() : execution(* ToBeAdvised.*(*,..)) { ... } I have never seen that before. Does it mean that you capture all the=20 methods that have more than zero arguments? Well, in that case, I have=20 to say two things: - if you want to implement my example, you have to write two pieces of=20 advice (one for the case argCount is 0 and one otherwise). I don't think=20 that it is very nice or readable. - what if you want to do something special in case there are 3 arguments=20 (for instance)? > * in general, bind the contextual information you need explicitly,=20 > giving you typed advice and no overhead Yep, but it will also give you less reusable advice code and pointcuts=20 (LESS reusable aspects in general). Sometimes, you want to perform=20 GENERIC actions, with minimal information, but with no overhead. It is=20 most of the time not possible with AspectJ. > * use thisJoinPointStaticPart (or the static parts of thisJoinPoint,=20 > which will be optimised to give the same result) I'd like too, but sometimes I'd like not. > * only use the full thisJoinPoint object when you really need runtime=20 > access to the actual this, target, and args objects (and then there are= =20 > lazyTjp optimizations that will also kick in) I don't know about this. Is it some kind of partial evaluation? Spoon=20 already support partial evaluation during the weaving process. That's=20 why it is so fast in my example, without requiring any special JVM=20 enhancements. >=20 > The JoinPoint implementation is also not based on java.lang.reflect=20 > under the covers (you state otherwise). Ooops! I will change it, but I would be very interested in knowing=20 exactly how it is done then, because I lack time to dive into AspectJ=20 sources... Note that java.lang.reflect is very optimized nowadays and=20 that's why I assumed that it was use here. I'm surprised. >=20 > In what way do you believe Spoon-AOP is "better typed" than most of the= =20 > classical AOP approaches? Can you give an example where Spoon-AOP has=20 > stronger typing than an equivalent AspectJ program? Well, I never said that Spoon-AOP was better-typed that AspectJ.=20 Actually, as far as I can tell it is just as well typed. But, what is interesting here, is that Spoon-AOP is not a new language,=20 but a pure Java framework that uses CT-reflection to extends the Java's=20 semantics. So, compared to the framework approaches (JAC, JBoss-AOP,=20 Spring...), Spoon-AOP is much better typed. Also, I think that Spoon-AOP is easier to use than AspectJ for a similar=20 type safetyness and better performances. For instance, with AspectJ, you have to bind the parameters you use when=20 you want type safety and performance. With Spoon-AOP, you can do it in=20 several ways. For instance to advise this method: @A void m(int i, String s) { ... } You can write this advice: @A @Before void a(int i,String s) { System.out.println("args=3D"+i+","+s); } This is kind of similar to AspectJ where you have to bind the parameters=20 explicitly... BUT it is not reusable. Indeed, it is efficient but it=20 does not work for any number of parameters. A more reusable way of doing=20 it in Spoon-AOP, would be: @A @Before void a() { System.out.print("args=3D"); if(_argumentCount_>=3D1) System.out.print(","+_arguments_[0]); if(_argumentCount_>=3D2) System.out.print(","+_arguments_[1]); if(_argumentCount_>=3D3) System.out.print(","+_arguments_[2]); System.out.println(); } These look like untyped argument accesses, but actually they are not.=20 Indeed _arguments_ does not represent the runtime arguments, but **the=20 compile-time argument accesses**. Then, the compilation phase for the=20 woven code will perform the type checking. For instance, with the method=20 m(int i, String s), the woven code will be (after partial evaluation): void m(int i, String s) { System.out.print("args=3D"); System.out.print(","+i); System.out.print(","+s); System.out.println(); ... // original m code } ..., which is more efficient than a reflective version... (Note that I could also make a foreach loop (finite loop), but my=20 partial evaluator does not know how to deal with these yet.) Whatever, I feel like I said too much already and that nobody will read=20 this. Once again, this is ongoing work and I am sure that there are=20 still a lot of defects. Also, it will be hard to defend it by myself if=20 nobody comes and see what it does exactly... So I'd like to encourage=20 anybody that would have some extra time to try it and to report on it :) Cheers, /Renaud >=20 > Renaud Pawlak wrote: >=20 >> Dear all, >> >> It is my pleasure to announce here the first release of Spoon: a=20 >> powerful Java 5 annotation processing tool. >> >> It is available in Open Source at http://spoon.gforge.inria.fr/ >> >> Spoon is similar to APT=20 >> (http://java.sun.com/j2se/1.5.0/docs/guide/apt/GettingStarted.html)=20 >> except that it provides a full metamodel of Java 5 (also models the=20 >> Java code in the method bodies) and that it implements compile-time=20 >> reflection. So, Spoon can be used for more in-depth and fine-grained=20 >> program transformation and analysis. >> >> In addition, for specifying the transformations, Spoon allows the use=20 >> of pure-Java templates (which can be compared to Velocity templates=20 >> except that they are written in Java and, as such, directly benefit=20 >> the IDE support for type soundness, navigation, and other features). >> >> Finally, let me point out for you a small application of Spoon: an=20 >> original and efficient annotation-driven AOP weaver called "Spoon-AOP"= =20 >> available at http://www.lifl.fr/~pawlak/spoon-aop/ >> >> Enjoy! >> /Renaud >> >=20 >=20 >=20 > __________________________________________________ > AOSD Discuss mailing list - di...@ao... > To unsubscribe go to http://aosd.net >=20 > Check out the AOSD.net Wiki: http://aosd.net/wiki >=20 --=20 Renaud Pawlak Researcher INRIA Futurs - Projet JACQUARD LIFL, UMR CNRS 8022, Equipe GOAL - B=E2timent M3 59655 Villeneuve d'Ascq C=E9dex - FRANCE Phone: (+33) 3 28 77 85 79 Cell: (+33) 6 62 00 19 19 Fax: (+33) 3 28 77 85 37 Emails: ren...@in... / pa...@li... WWW: http://www.lifl.fr/~pawlak |