Community
Participate
Working Groups
I am referring to my mailing list discussion with Andy and will quote my suggestion from there: http://aspectj.2085585.n4.nabble.com/Can-I-force-around-advice-especially-for-constructors-to-be-inlined-td4652728.html ------------------------------------------------------------ Actually it would be really good if inlining could be forced, e.g. globally with a compiler switch or per aspect/advice with an annotation, e.g. @Inline, if necessary with additional annotation parameters instructing the compiler to only inline into constructors or whatever. The annotation would work as a compiler directive in both native syntax and @AspectJ style. The idea to (optionally) do more or even heavy inlining would be really helpful for people who want to retransform loaded classes and not just weave them during class loading. That would open up whole new ways of AspectJ application incl. JDK weaving during runtime. I have played with byte code engineering frameworks a bit lately, e.g. advising bootstrap classes via ByteBuddy advice. I have also implemented what I showed you here in Javassist, and it also works with bootstrap classes, even already loaded ones, as long as all transformations are inlined. The downside is the boilerplate I need in order to identify "joinpoints" for my transformations because I cannot use AspectJ's matcher. Well, in theory maybe I could (like Spring AOP does), but not the rest of AspectJ. There are so many interesting options with inlining, until three weeks ago I had no idea how much is possible.
Something seems to be wrong with the nabble.com link, so here are other sources pointing to the same mailing list thread: https://www.eclipse.org/lists/aspectj-users/threads.html#15451 https://www.mail-archive.com/aspectj-users@eclipse.org/msg09024.html
We have an interesting new incarnation of this problem here: https://stackoverflow.com/q/70411097/1082681 The corresponding MCVE is here: https://github.com/DaGeRe/aspect-final-example What is interesting is that actually a field-set pointcut fails for a final field which is initialised during declaration, i.e. for some reason excluding field-set joinpoints does not work. It looks as though the field initialiser is extracted into an around advice during weaving, i.e. excluding write access comes too late. We should consider this situation too when introducing advice inlining.