Hi Andy. I finally got around to trying the ITD/interfac/decp route, but the introduced methods access class member, so it will not work that way unless the class gets refactored to actually also get its members via ITD, which is not an option. The mock approach might be the only one remaining here, but the mocks would also need to have the members in them. That is almost as bad as having a direct dependency on the java lib. Actually I think the whole setup is not so well designed, I was just trying to help someone on StackOverflow because the problem as such intrigued me. Simulating the mocks' existence within the compiler would be the magic solution for me - you would have all the work, I would have none ;-) - but I guess that this is too esoteric for me to ever expect you to take time to implement it.
Thanks for your thoughts and great ideas. -- Alexander Kriegisch http://scrum-master.de Andy Clement schrieb am 23.10.2014 17:53: > Obviously it can depend to some degree how coupled they need to be to those > targets, as I’m sure you’ve realized. If I ITD on an interface and then use > a declare parents with a wild carded pointcut or an annotation based pointcut > to introduce that interface to some java classes, I can build all that without > needing the exact target. > > If I do need to target a specific class though, you can’t do it. We rely on a > coherent type system during compilation once all the aspects have been > resolved > and done their thing (added methods/fields, changed hierarchies, etc). You > could compile against mocks that represent the eventual real targets because > the aspects that are built are reusable. So create a jar with your aspects in, > ditch the mocks and then you have a reusable library. > > @DeclareMixin enables some of this too, as when it is used you can just > utilize > javac to build it, but it is quite similar to the ITD/interfac/decp route > really. > > It sounds messy to get it working in the general case (I guess I - in the > compiler - would be simulating the existence of those mocks). > > cheers, > Andy > >> On Oct 23, 2014, at 4:37 AM, Alexander Kriegisch <alexan...@kriegisch.name> >> wrote: >> >> Sorry, this might be a stupid question with regard to an obvious "hen vs. >> egg" >> problem, but I am asking anyway: >> >> The beauty of aspect libraries is that they can be compiled separately and >> woven later, either by compiling it into Java (source or binary) code via ajc >> or by applying them via LTW. This works for most "normal" aspects. So far, so >> good. >> >> Aspects using ITD, e.g. adding methods or members to existing Java classes, >> are different though. It seems they cannot be compiled with ajc into separate >> libraries without them accessing the target Java classes. While this makes >> sense logically, it causes a modularity problem as follows: Say we have a >> Maven project containing a Java library and and AspectJ library. The Java >> library without aspects is a valid artifact and can be used normally. Another >> aspect-enhanced JAR should be an additional artifact created by combining the >> AspectJ library and the Java library. But this would require the AspectJ >> library to be compileable without a dependency on the Java library. This >> would >> also allow me to have separate aspect libraries doing ITD on the same target >> classes. >> >> My explanation looks awkward to myself, but I hope you understand anyway. My >> question is: Is there a way to compile ITD aspects independently from the >> target classes and later weave them into those very target classes, similar >> to >> LTW where aspects are compiled but unfinished until woven into the classes? >> Or >> would it be at least thinkable to have such a feature in the future? >> -- >> Alexander Kriegisch >> http://scrum-master.de >> _______________________________________________ >> 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
