Re: [aspectj-users] ajc 1.6.6 -> 1.6.7+ behavior changes ?

[Andy Clement <andrew.clement@xxxxxxxxx>]

Hey,

Yes, Romain sent me some repo references off list so the discussion ended up continuing there. I was planning to post back here when we got to a conclusion (which we just did last night when Romain tested a 1.8.6 snapshot I created with a potential fix).

The new method will make it into the class file proceedOnError, but of course that isn’t where the compiler is looking. The compiler is looking at the raw type binding for Glyph, and that has a super type of Object.  Sometime after that raw type representation is built we apply the declare parents and it changes the super type of the generic type of Glyph to the new type that contains the missing methods.  When the classfiles are written out, they’ll be based on the generic type so the correct declare parented super type will be there but for all the non generic references made in the program, they will being resolved against the raw type which does not have these methods in its hierarchy.

I don’t quite understand why this is only coming up now, looks to have been missing for a long time.  Possibly it is the use of declare parents extends (with generics), that is just not as common as declare parents implements.

The fix is simply to have a look for a raw type when patching up the generic type and fix that up too, possibly there is an issue with parameterized types too but I have no test program that shows me there is an issue (yet).

A proceed on error without the fix would probably leave the code with eclipse exception throwing code generated at the bad method call sites that would fail at runtime when exercised. I never recommend proceedOnError.

cheers,
Andy

> On Apr 11, 2015, at 5:47 AM, Alexander Kriegisch <Alexander@xxxxxxxxxxxxxx> wrote:
> 
> Sounds good, Romain, I had no idea Andy was in touch with you.
> 
> BTW, I noticed that if you add
>    <proceedOnError>true</proceedOnError>
> to the POM of zvtm-cluster, the build continues and the necessary methods seem to be there in the resulting class files. Can you please test that with the official v1.8.5 (not the fixed preview) and tell me if the software actually does what it is supposed to? I have no idea how to test that because I do not know ZVTM. I am just curious if this workaround to keep the build going actually works or leaves behind inconsistently woven class files.
> 
> Thanks in advance
> -- 
> Alexander Kriegisch
> http://scrum-master.de
> 
> 
> Romain Primet schrieb am 11.04.2015 14:35:
> 
>> Hi Alexander,
>> 
>> I got a reply from Andy off-list; looks like an issue with ITD and 
>> generic types (ITD not being done on raw type). I'm sure Andy will be 
>> more precise; also, he has provided me with a snapshot build of aspectj 
>> that builds zvtm-cluster just fine.
>> 
>> Thanks a lot to you both for the debugging and help!
>> 
>> Romain
>> 
>> Le 11/04/2015 14:31, Alexander Kriegisch a écrit :
>>> Hi Andy.
>>> 
>>> I have looked into this a little more and noticed that the build within
>>> Eclipse Luna with AJDT works nicely, but fails with AspectJ Maven Plugin and
>>> on the command line via ajc.bat. So this might be a clue what it going wrong
>>> if you can answer one question: What does ADJT differently in comparison to
>>> Ajc with regards to build order or other relevant factors?
>>> 
>>> I have also noticed that if I remove the three Aspect files
>>>   - GlyphCreation.aj
>>>   - GlyphReplication.aj
>>>   - VirtualSpaceReplication.aj
>>> from zvtm-cluster, the module compiles fine. This is because these aspects
>>> rely on ObjIdIntroduction.aj being woven first as they expect the introduced
>>> methods to be present in the target classes from module zvtm-core.
>>> 
>>> I also tried to replicate a minimal sample with a Java project and an AspectJ
>>> project having the Java project on its inpath. The AspectJ project has three
>>> aspects which rely on each other's methods being present. It does not show any
>>> errors during compilation from either Eclipse or command line though. So
>>> probably you need to analyse the real project. To me it definitely looks like
>>> a bug.
>>> 
>>> Regards
>> 
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from
>> this list, visit
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users