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.pri...@gmail.com> 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.clem...@gmail.com > <mailto:andrew.clem...@gmail.com>>: > 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 <alexan...@kriegisch.name> > > 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 <tel:%2B49%20%289193%29%2052%2076>, Mob +49 (176) 20 > > 53 07 02 <tel:%2B49%20%28176%29%2020%2053%2007%2002> > > > > > > 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 <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 <mailto: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 > >>>> <https://dev.eclipse.org/mailman/listinfo/aspectj-users> > >>>> > >>> _______________________________________________ > >>> aspectj-users mailing list > >>> aspectj-users@eclipse.org <mailto: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 > >>> <https://dev.eclipse.org/mailman/listinfo/aspectj-users> > >> > >> _______________________________________________ > >> aspectj-users mailing list > >> aspectj-users@eclipse.org <mailto: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 > >> <https://dev.eclipse.org/mailman/listinfo/aspectj-users> > >> > > > > _______________________________________________ > > aspectj-users mailing list > > aspectj-users@eclipse.org <mailto: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 > > <https://dev.eclipse.org/mailman/listinfo/aspectj-users> > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org <mailto: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 > <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
