Much appreciated Andy! On Thu, Nov 2, 2017 at 9:12 AM, Andy Clement <[email protected]> wrote:
> I've only just done the 1.8.12 release so 1.8.13 is a little way off > (christmas?). There may be a 1.9.0.RC2 before that (1.9.0 also includes the > fix). > > cheers, > Andy > > On 1 November 2017 at 15:44, Jason Britton <[email protected]> wrote: > >> 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 <[email protected] >>>> > 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 <[email protected]> >>>>> 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 >>>>> [email protected] >>>>> 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> 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 >>>> [email protected] >>>> 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 >>> [email protected] >>> 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 >>> [email protected] >>> 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/aspectj-users
