From 52cf27188372c0b375aaaad367d2cb311e0df05b Mon Sep 17 00:00:00 2001 From: wisberg Date: Thu, 13 Nov 2003 09:04:12 +0000 Subject: updates listed in q:faqchanges. Many more to harvest from the list, and to move from here and the list to the programming guide. --- docs/faq/faq.xml | 327 +++++++++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 295 insertions(+), 32 deletions(-) diff --git a/docs/faq/faq.xml b/docs/faq/faq.xml index 8634929d9..d3aa72f07 100644 --- a/docs/faq/faq.xml +++ b/docs/faq/faq.xml @@ -23,7 +23,7 @@ 2003 Contributors. All rights reserved. - Last updated November 5, 2003. + Last updated November 13, 2003. This FAQ covers AspectJ versions 1.0 and 1.1. @@ -1333,7 +1333,9 @@ aspect PublicErrorLogging { Can I use AspectJ with Generic Java? - At this time, unfortunately not. The two compilers are just not + We plan to support Generics when Java 1.5 is available. + + But at this time, unfortunately not. The two compilers are just not at all compatible. In an ideal world, there would be a wonderful Open Source extensible compiler framework for Java that both GJ and AspectJ would be built on top of, and they would seamlessly @@ -1354,6 +1356,24 @@ aspect PublicErrorLogging { + + + Can I use AspectJ with J2ME? + + + We have not tested with J2ME, but we understand that users + are deploying AspectJ-compiled programs successfully in J2ME. + It should work if your program is otherwise J2ME-compatible + and if you avoid using cflow-based pointcuts + or thisJoinPoint. + To ensure that the program is limited to J2ME API's, + you should supply the runtime on the bootclasspath. + (Fair warning: there was an email about this not working, + but there has been no bug report.) + + + @@ -2652,6 +2672,12 @@ aspect MyMarker extends MarkerExample { Some examples are distributed in the documentation release, and you can find other code in the discussions on the users list. + In the AspectJ CVS tree, there are prospective code samples in the + docs module sandbox + and teaching directories. + (Until they are published, these samples should be used only by + programmers who can determine for themselves whether they + are correct.) @@ -3159,9 +3185,11 @@ vmparam -Xmx384m - When advice is not running, it is probably a problem in the - pointcut. - Sometimes users specify pointcuts that do not mean what they intend - + + When advice is not running, + there is probably a problem in the pointcut. + Sometimes users specify pointcuts that + do not mean what they intend - most often when they misspell a type name. Run the compiler in -Xlint mode, which will flag some likely mistakes, like the type name. @@ -3172,21 +3200,101 @@ vmparam -Xmx384m see if your join points are executing at all by using TraceJoinPoints.java from . - When advice is running more than it should, it may be that your - pointcut picks out more join points than you intend. + When advice is running more than it should, either + (1) your advice is in an abstract aspect and the pointcut picks + out the same join point for more than one concrete instantiation + of the aspect, or + (2) your pointcut picks out more join points than you intend. + + + In the case of advice in abstract aspects, the advice will run once + for each concrete instance of the aspect. + If the pointcut for that advice picks out the same join point for two + concrete aspects, then the correct behavior is for the advice to run + the advice twice at that join point. + + + To see if your pointcut picks out the join points you intend, you + can use IDE support, logging, or declare-warnings. If you are using IDE support, you should be able to trace back from the pointcut or advice to the join points which can be statically - determined to be affected. To identify advised dynamic join points, + determined to be affected. + Without IDE support, you can write + declare-warning statements to identify code affected by staticly- + determinable pointcuts. + To identify advised dynamic join points, you can try using TraceJoinPoints.java as above, or update the advice to print the source location of the join point. - This will show if the advice applies to code that you did - not consider. - + Doing any of these should show if the advice applies to code that + you did not expect. + If you've done this and convinced yourself it's not working, it may be a bug. See . + + + + My advice runs for each overridden method! + + + + Most likely you are advising the method execution join + point and specifying the defining signature. + Since all overriding methods share this signature, + the advice runs for each method executed. + (This happens, e.g., when one method invokes the same method + in the superclass using super.{method}(..)). + This is the correct behavior. + + To avoid this, use the call(..) pointcut + designator, or use !cflow(..) to pick + out only the initial method-execution. + + + + + + + I don't understand when thisEnclosingJoinPointStaticPart is available. + + + + + thisEnclosingJoinPointStaticPart is a special + variable available in the context of advice to refer to the + join point, if any, lexically enclosing the current join point: + + thisEnclosingJoinPointStaticPart + + + + One of these... + will be tEJSP for each of these: + + + + constructor-execution, method-execution, + advice execution, initialization, + pre-initialization, static initialization + + + constructor-call, method-call, handler, + field-set, field-get + + + + +
+ Expressions in the body of handlers have the same + thisEnclosingJoinPointStaticPart + as the handler itself. + + + @@ -3204,6 +3312,29 @@ vmparam -Xmx384m + + + + This is true. The workaround is to compile all the top-level implementating + classes of the interface using ajc. + From an email by Jim Hugunin on the requirements for AspectJ 1.1 to + implement members declared by an aspect on an interface: + + + If you introduce non-static fields or non-abstract methods on an interface + from an aspect, then all of the top-most implementors of that interface must + be woven by that same aspect. + (A class C is a top-most implementor of an interface I if C implements I + and the superclass of C does not implement I.) + + + + + + + + @@ -3334,6 +3465,41 @@ vmparam -Xmx384m + + + Why can't AspectJ pick out local variables (or array elements or ...)? + + + + Users have sometimes wanted AspectJ to pick out + many more join points, including + + method-local field access + array-element access + loop iteration + method parameter evaluation + + Most of these have turned out not to make sense, + for a variety of reasons: + + it is not a commonly-understood unit for Java programmers + there are very few use-cases for advice on the join point + a seemingly-insignificant change to the underlying program + causes a change in the join point + pointcuts can't really distinguish the join point in question + the join point would differ too much for different + implementations of AspectJ, or would only be implementable + in one way + + + We prefer to be very conservative in the join point model for the language, + so a new join point would have to be useful, sensible, and implementable. + The most promising of the new join points proposed are for exception + throws clauses and for synchronized blocks. + + + @@ -3512,16 +3678,81 @@ vmparam -Xmx384m - There are currently no documents describing this process in any detail. - Currently, the best way to understand this is to compile programs and - then inspect the generated source or bytecode. Many people have found - this very effective for understanding the weaving model. You also have - access to the source code for a different perspective. (See - ). - We hope to write - a couple of papers on the bytecode weaving model used in AspectJ-1.1 if - we can ever find the free time. - + There are currently no documents describing this process in detail. + You can compile programs and inspect the generated source or bytecode, + or view the source code (see ). + We hope to write papers on the bytecode weaving model used in + AspectJ-1.1 if we can find the time. + Erik Hilsdale and Jim Hugunin did draft a paper for AOSD 2004, + now available on Jim's web site: + + http://hugunin.net/papers.html + Jim summarized advice weaving in the AspectJ 1.1 implementation in the + + following mailing-list reply: + + + Each piece of advice in an aspect is associated with a pointcut. + This pointcut is stored in an attribute on the methods + corresponding to each piece of advice. + Before weaving, all of these pieces of advice are gathered + into one large list. + + + Each .class file is woven independently. + A .class file is woven by the following steps: + + + Collect all of the joinpoint shadows in the .class file. + For every dynamic joinpoint in the AspectJ language model, + there is a corresponding static shadow of that joinpoint + in the bytecode. + For example, every method call joinpoint has an INVOKE + bytecode as its static shadow. Some joinpoints + (such as initialization) have much more + complicated static shadows. + + + Each piece of advice is matched to each static shadow. + There are three results possible from this match. + + + Never matches, + in which case nothing is done to the shadow + + + Always matches, + in which case the advice is woven into this joinpoint shadow + + + Sometimes matches, + in which case the advice is woven into the shadow + along with the minimal dynamic tests to determine + if any particular joinpoint in the actual running + program matches the advice. + The simplest example of sometimes matches is + when the pointcut uses if(test()). + + + + + If any advice matched any static shadows in the .class file, + then the transformed .class file is written out, + otherwise it is left unchanged. + + + See BcelClassWeaver and + BcelShadow in the + org.aspectj.weaver.bcel package + for the two primary classes involved in this process. + + + + Note: This explanation ignores the implementations of inter-type + declarations completely. + It also ignores performance optimizations such as fast-match + that speed up the weaving process. + @@ -3576,11 +3807,9 @@ vmparam -Xmx384m AspectJ Project Development - + I'm interested in the code implementing AspectJ. - How can I get involved with developing the AspectJ project? @@ -3589,8 +3818,9 @@ vmparam -Xmx384m and tools for writing AspectJ programs. For people who want to know how the AspectJ technology works, - the source code is the best resource. - There are no white papers or high-level design documents for AspectJ. + the source code is the best resource, until we write some + proper white papers + (see ). To get and compile the Java source code for the AspectJ distribution, see . @@ -3600,6 +3830,15 @@ vmparam -Xmx384m might be an initial version of a new architecture (e.g., bytecode weaving). + + + + + How can I get involved with developing the AspectJ project? + + + For those who want to contribute to the project, here's a general list of ways to do so, in no particular order: @@ -3616,6 +3855,15 @@ vmparam -Xmx384m for fixing bugs or adding features. + + Write bugs. Good bugs, especially with test cases, + are always appreciated. We especially like proposals for + new XLint messages, since they are + sometimes easy to implement and help users learn + AspectJ, and for other implementable features + grounded in a compelling use-case. + + Write test cases for compiler bugs without test cases. Compiler bugs without test cases are much less likely to be fixed; @@ -3983,13 +4231,17 @@ vmparam -Xmx384m - It is generally most effective to do a google search of the form, + It is very effective to do a google search of the form, http://www.google.com/search?q=site:eclipse.org+cflowbelow - - but this may not get results inside the mail archives. - Be sure to check the old archives available for download from - the AspectJ home page. + , + and you can use the eclipse.org search at + + http://www.eclipse.org/search/search.cgi + . + You can also check the old archives available for download from + the AspectJ home page + http://eclipse.org/aspectj . @@ -4190,6 +4442,17 @@ vmparam -Xmx384m + + + + + + + + + + + -- cgit v1.2.3