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