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 <alexan...@kriegisch.name>
>> 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@eclipse.org
>>> 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@eclipse.org
>> 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@eclipse.org
> 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@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
