Fantastic!!! Thank you for fixing! How long does it take a SNAPSHOT to make it to release?
On Wed, Nov 1, 2017 at 3:25 PM, Andy Clement <andrew.clem...@gmail.com> wrote: > It is fixed up. It was the order of processing as suspected, it can also > vary on the same OS ( I can make it fail on my mac by passing A last ). > > Because ordering is not supposed to be important we don’t sort source file > inputs. This means you can be at the mercy of what your JVM decides to do. > As types go through the compilation pipeline they are initially represented > by an eclipse type then later on by a binary byte code based type. The > code to verify the rules of declare parents was encountering one of the > types in one form when it worked and in the other when it failed. > > if you grab a 1.8.13.BUILD-SNAPSHOT from the maven repo > repo.spring.io/snapshot then you’ll pick up the fix. I confirmed that > fixes your sample. > > cheers, > Andy > > On Nov 1, 2017, at 12:05 PM, Jason Britton <jbritto...@gmail.com> wrote: > > Thanks for investigating. What's strange is I'm using IntelliJ on a Mac > (using the Maven project) and I get the compilation error. > > On Wed, Nov 1, 2017 at 10:59 AM, Andy Clement <andrew.clem...@gmail.com> > wrote: > >> Thanks for the test project. It compiled fine for me on Mac but then I >> thought I’d try windows and sure enough over there it fails. It may be the >> order of the processing of the files (which can vary across OS), digging >> into it now. >> >> Andy >> >> On Oct 31, 2017, at 4:41 PM, Jason Britton <jbritto...@gmail.com> wrote: >> >> Hi Andy - >> Thanks for looking into. I've created a public github repo with a maven >> project that recreates the issue here: https://github.com/JOBr >> itton/aspectj-generics-issue >> >> Let me know if you are able to reproduce. Thanks! >> >> Jason >> >> On Tue, Oct 31, 2017 at 1:19 PM, Andy Clement <andrew.clem...@gmail.com> >> wrote: >> >>> I recall in the early days of AspectJ 5 we had a mountain of issues like >>> this, but I thought they’d all been ironed out ! >>> >>> Hmm, I guess there must be a little more to it, here are my source files >>> that simulate what you wrote: >>> >>> --- >>> import java.util.*; >>> interface A<T extends BaseT,I extends BaseI> { >>> T setInputs(List<I> inputs); >>> } >>> --- >>> import java.util.*; >>> public class AlreadyImplementsA { >>> public ConcreteTImpl setInputs(List<ConcreteIImpl> inputs) { >>> return null; >>> } >>> } >>> --- >>> interface BaseI {} >>> --- >>> interface BaseT {} >>> --- >>> class ConcreteIImpl implements BaseI {} >>> --- >>> class ConcreteTImpl implements BaseT {} >>> --- >>> public aspect BindInterfaceA { >>> declare parents: AlreadyImplementsA implements A<ConcreteTImpl, >>> ConcreteIImpl>; >>> } >>> --- >>> >>> >>> -> ajc -1.8 A.java BaseT.java AlreadyImplementsA.java BaseI.java >>> ConcreteIImpl.java ConcreteTImpl.java -outjar code.jar >>> >>> >>> -> ajc -inpath code.jar -showWeaveInfo BindInterfaceA.java -outjar >>> code2.jar >>> Extending interface set for type 'AlreadyImplementsA' >>> (AlreadyImplementsA.java) to include 'A<ConcreteTImpl,ConcreteIImpl>' >>> (BindInterfaceA.java) >>> >>> -> javap -classpath code2.jar AlreadyImplementsA >>> Compiled from "AlreadyImplementsA.java" >>> public class AlreadyImplementsA implements A { >>> >>> >>> Are you applying the aspect via binary weaving? I do notice a >>> difference in separate compilation vs all source: >>> >>> -> ajc -1.8 *.java -showWeaveInfo -outjar foo.jar >>> Extending interface set for type 'AlreadyImplementsA' >>> (AlreadyImplementsA.java) to include 'A<ConcreteTImpl,ConcreteIImpl>' >>> (BindInterfaceA.java) >>> >>> -> javap -classpath foo.jar AlreadyImplementsA >>> Compiled from "AlreadyImplementsA.java" >>> public class AlreadyImplementsA implements A<ConcreteTImpl, >>> ConcreteIImpl> { >>> >>> Note that in the binary weaving case the type parameters are missing on >>> the implements clause. >>> >>> How are you building it? Can you adapt my steps above to show the fault. >>> >>> cheers, >>> Andy >>> >>> On Oct 30, 2017, at 2:11 PM, Jason Britton <jbritto...@gmail.com> wrote: >>> >>> Hi - >>> I'm running into a perplexing issue with AJC and I'm hoping someone else >>> has seen this before. >>> >>> The target of my aspect is the class AlreadyImplementsA, we are simply >>> wanting to throw the 'implements A' onto this class. AlreadyImplementsA >>> class already does indeed implement every method defined by the interface >>> A but for whatever reason, AJC complains that AlreadyImplementsA does Not >>> implement A because of the method >>> >>> T setInputs(List<I> inputs); >>> >>> >>> I can have a whole multitude of other methods defined on the interface >>> and AJC does not complain, it seems to have a problem with the fact that >>> the argument to the method on the interface is an Interface (List) with a >>> generic I. As I have other AJC issues where the method argument is a Map >>> of a generic type and AJC blows up on it as well. >>> >>> My aspect below >>> >>> public aspect BindInterfaceA { >>> >>> declare parents: AlreadyImplementsA implements A<ConcreteTImpl, >>> ConcreteIImpl>; >>> >>> } >>> >>> >>> My interface *A* referenced above has an interface method defined as shown >>> below >>> >>> >>> public interface A<T extends BaseT, I extends BaseI> { >>> >>> T setInputs(List<I> inputs); >>> >>> } >>> >>> >>> The 'exact' AJC error message is >>> >>> AlreadyImplementsA must implement the inherited abstract method >>> A<ConcreteTImpl, ConcreteIImpl>.setInputs(Pjava/util/list<LConcreteIImpl;>;) >>> >>> >>> I am almost positive the problem all boils down to an interface with a >>> generic being passed as a argument to the method (List<I> inputs) in our >>> case, which is causing AJC problems. >>> >>> Thanks for any advice you might have on getting past this. >>> >>> >>> Jason >>> >>> >>> _______________________________________________ >>> 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 >
_______________________________________________ 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
