Thanks Andy, best explanation ever of Java field initialization as it
relates to AspectJ.
 On 23/07/2013 8:15 AM, "Andy Clement" <andrew.clem...@gmail.com> wrote:

> Some background on Q1:
>
> public class Child {
>
>     public String name = "John";
>
>     public Child(String desc) {
>     }
>
>     public Child(int bar) {
>     }
> }
>
> When this code is compiled the bytecode to set name to 'John' is included
> in every constructor within the class (without anything to mark that
> bytecode as existing due to field initialization). It isn't put into some
> other static 'initializer' method that can be invoked separately:
>
>   public Child(java.lang.String);
>     Code:
>       stack=2, locals=2, args_size=2
>          0: aload_0
>          1: invokespecial #1                  // Method
> java/lang/Object."<init>":()V
>          4: aload_0
>          5: ldc           #2                  // String John
>          7: putfield      #3                  // Field
> name:Ljava/lang/String;
>         10: return
>
>   public Child(int);
>     Code:
>       stack=2, locals=2, args_size=2
>          0: aload_0
>          1: invokespecial #1                  // Method
> java/lang/Object."<init>":()V
>          4: aload_0
>          5: ldc           #2                  // String John
>          7: putfield      #3                  // Field
> name:Ljava/lang/String;
>         10: return
>
> When we separately compile the aspect, we have no idea which bytecode we
> might need to copy from existing constructors to initialize fields. In your
> case you are compiling the source for the target and the source for the
> aspect together so in compiling the aspect we could look at the target
> source, but a guiding principal of AspectJ is that separate compilation
> works the same as 'altogether' compilation so whether the aspect is
> compiled with the target sources or against the bytecode for that target,
> it must do the same thing. This means if information cannot be determined
> from the bytecode, we just don't know it.
>
> Andy
>
>
>
> On 17 July 2013 06:12, pai <pika...@gmail.com> wrote:
>
>> Hi thanks! so it seems for Q1, it's apsecJ's limitation.
>>
>> Thank you for the information :)
>>
>> I'll post Q2 question in another thread.
>>
>> Regards!
>>
>>
>>
>> --
>> View this message in context:
>> http://aspectj.2085585.n4.nabble.com/Behaviours-of-new-constructor-added-by-AspectJ-ITD-tp4651015p4651028.html
>> Sent from the AspectJ - users mailing list archive at Nabble.com.
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Reply via email to