Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] ajc 1.6.6 -> 1.6.7+ behavior changes ?

Hi Romain,

It should be in - I can see the fix in the git log (although I wish we’d tracked this in a real bugzilla rather than just in email). Are you sure you aren’t hitting something new now, having changed a bit of code?

cheers,
Andy

On Jul 6, 2015, at 5:33 AM, Romain Primet <romain.primet@xxxxxxxxx> wrote:

Hi Andy,

Contacting you again abount this issue, did the fix make it into 1.8.6? We get the same errors at compile time.

Cheers

Romain

2015-04-12 19:53 GMT+02:00 Andy Clement <andrew.clement@xxxxxxxxx>:
Nope I have no testcase, I couldn’t recreate it in a simple scenario after trying for a little while so had to work on it in Romains complete app. Sometimes I don’t have the cycles to get a lovely regression test in place :(


cheers,
Andy

> On Apr 12, 2015, at 8:02 AM, Alexander Kriegisch <Alexander@xxxxxxxxxxxxxx> wrote:
>
> Hi Andy.
>
>> Possibly it is the use of declare parents extends (with generics),
>> that is just not as common as declare parents implements.
>
> Actually, no. That was the first thing I tried, namely getting rid of the interface implementation 'DefaultIdentifiable' and replacing it like this:
>
>
> package fr.inria.zvtm.cluster;
>
> import fr.inria.zvtm.engine.Camera;
> import fr.inria.zvtm.engine.VirtualSpace;
> import fr.inria.zvtm.glyphs.Glyph;
> import fr.inria.zvtm.engine.portals.Portal;
>
> aspect ObjIdIntroduction {
>    declare parents: VirtualSpace implements Identifiable;
>    declare parents: Glyph        implements Identifiable;
>    declare parents: Camera       implements Identifiable;
>    declare parents: Portal       implements Identifiable;
>
>    private final ObjId Identifiable.objId = ObjIdFactory.next();
>    private boolean Identifiable.replicated = false;
>
>    public ObjId Identifiable.getObjId(){ return objId; }
>    public boolean Identifiable.isReplicated() { return replicated; }
>    public void Identifiable.setReplicated(boolean val) { this.replicated = val; }
> }
>
> The resulting compilation errors were the same as before. I actually tried to replicate the generics situation in a simple project, but have failed to do so. Do you have a test case for it? Well, probably I should just look at your Git repo and check the latest commits (if you have pushed them already).
>
> Regards
> --
> Alexander Kriegisch
>
> Schillerplatz 6, 91315 Höchstadt, Germany
> Tel +49 (9193) 52 76, Mob +49 (176) 20 53 07 02
>
>
> Andy Clement schrieb am 11.04.2015 18:56:
>
>> 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
>>
>> _______________________________________________
>> 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

_______________________________________________
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


Back to the top