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>:
> 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, 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
>
> _______________________________________________
> 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
