Re: AlRe: [Fwd: Re: [aspectwerkz-dev] Creating AOPified javadocs]

Quote Alex::

> In Tiger, annotations are not in javadoc and are strong typed thru the help
> of an interface.
> 
> @Before(myPointcut)
> public void myBeforeAdvice(...)
> 
> java sources with javadoc + javac compiled + AW AnnotationC tool generates
> new class files (offline)
> just as
> java sources with annotations + javac Tiger compiled class files
> 
> produce class files where annotations are represented in the bytecode.

I went to code to better understand this. As far as i get it, AdviceInfo-s are added as attributes 
at allowed/interesting points. What I am not sure I understood is the following:

according to JVM spec the attribute struct is

attribute_info {
     u2 attribute_name_index;
     u4 attribute_length;
     u1 info[attribute_length];
}

it seems to me that info is just a byte array and you use this for serializing AdviceInfo?


2. This is a separate question. In AsmHelper.loadClass(ClassLoader, byte[], String) you are using a 
loader to load ClassLoader and than invoke its defineClass method. Why are you using this mechanism? 
(In order to simulate the CL hierarchy?)

3. I saw the above method is used in 2 different compilers JitCompiler and JoinPointCompiler?
Where are these used? (I guess they are used at classloading for weaving, ain't it?). What is the 
difference between 'em and in which of the situation are used?

4. I am reading now the Advice Weaving in AspectJ (Hilsdale & Hugunin). The inline weaving you are 
working on will look like the described solution used by AspectJ?

::the_mindstorm

PS: I hope that I am not bothering too much with this kind of questions (but I am trying to get an 
inside view
> 
> Alex
> 
> 
> 
> ----- Original Message ----- 
> From: "Jack Tang" <[email protected]>
> To: <[email protected]>
> Sent: Friday, August 27, 2004 6:09 PM
> Subject: Re: [Fwd: Re: [aspectwerkz-dev] Creating AOPified javadocs]
> 
> 
> 
>><Quote>
>>
>>>>phase 1 and 2 are gone with J2SE 5.
>>>
>>>The solution must not take to much into account this, as i consider that
> 
> the switch to J5 will take
> 
>></Quote>
>>How about Tiger's javadoc? How does he solve *annotation* in javadoc?
>>
>>P.S: I am a stranger to Tiger
>>
>>/Jack
>>
>>
>>
>>On Fri, 27 Aug 2004 18:59:40 +0300, the_mindstorm
>><[email protected]> wrote:
>>
>>>Quote Alex::
>>>
>>>
>>>>Hi
>>>>Looks like you forgot the diagram.
>>>>How will you handle call pointcut matching at source level (and not
> 
> bytecode
> 
>>>>level) with QDox ? I don't think it is possible, since QDox does not
>>>>modelize method bodies.
>>>
>>>Correct. This is why I am thinking that the 1st solution is more suited.
>>>
>>>
>>c
>>
>>>a long time.
>>>
>>>
>>>>phase 3 is wrong may be: we do not parse javadoc tag. We parse
> 
> annotations
> 
>>>>in bytecode (that get there thru AnnotationC or J2SE 5 javac).
>>>
>>>Interesting. I missed this. Alex can you pls detail a little this
> 
> mechanism.
> 
>>>An interesting point is that the javadoc will use the compiler/weaver in
> 
> offline mode (or will use
> 
>>>the inline weaver ;-) ).
>>>
>>>
>>>>phase 4 is : weave class files as they gets loaded thru classloaders
> 
> (not
> 
>>>>java sources)
>>>>Or may be you confused me , since I made the assumption that those
> 
> phases
> 
>>>>were executing one after another.
>>>>
>>>>Some more ideas: As you may know AspectJ has a declare error construct
> 
> that
> 
>>>>allows to report design error based on pointcuts (ie : do not call new
>>>>Stuff() unless within the factory method code etc). The tool design
> 
> and the
> 
>>>>underlying weaver requirements should handle this as well.
>>>
>>>There are intentions in AW to support all the AspectJ features? Is there
> 
> a roadmap?
> 
>>>::the_mindstorm
>>>
>>>
>>>
>>>
>>>>Alex
>>>>
>>>>----- Original Message -----
>>>>From: "Jack Tang" <[email protected]>
>>>>To: <[email protected]>
>>>>Sent: Friday, August 27, 2004 4:53 PM
>>>>Subject: Re: [aspectwerkz-dev] Creating AOPified javadocs
>>>>
>>>>
>>>>
>>>>
>>>>>Hello Alexandru
>>>>>
>>>>>After reading Alex's comments, I think I got some points. If something
>>>>>wrong, please correct me, Alex.
>>>>>
>>>>>The key of this problem is when to collect aop model information and
>>>>>who will supply these information. Two solution list here:
>>>>>
>>>>>1.javac + weave classes + generate stubs and javadoc  [method 1 and
>>>>>method with emitted join points]
>>>>>2.parse sources + generate stubs and javadoc
>>>>>
>>>>>And I divide AW engine workflow into five phrase(maybe more,but here
>>>>>I think five is enough).
>>>>>1.hook phrase      : pipe BootClasspathStarter/JDWPStarter after
>>>>>java.lang.ClassLoader
>>>>>2.preProcess phrase: initialize preProcessor,filter certain CL and
> 
> modify
> 
>>>>CL
>>>>
>>>>
>>>>>3.parse phrase     : parse xml and javadoc @tags
>>>>>4.compile phrase   : compile Java source
>>>>>5.transform/weave phrase: weave the cross-cutting info
>>>>>
>>>>>diagram like this:
>>>>>(see attached file)
>>>>>
>>>>>Let's discuss solution 2 first. We should parse java sources by
>>>>>ourself using QDox, then parse xml def, finally we structure aop
>>>>>domain model by our hand. This solution is better to me first
>>>>>impression, because I dream he can avoid "compile phrase". But maybe
>>>>>it's my daydream.
>>>>>
>>>>>And if we refer to solution 1, "compile phrase" has to be involved,
>>>>>but we can access aop domain model easily through weaver context.
>>>>>
>>>>>
>>>>>/Jack
>>>>>
>>>>
>>>>
>>>>
>>>
>>
> 
>