| Re: [aspectj-dev] Re: [Bug 55107] add removeLibraryAspect method to weaver |
Hi,
I have moved the discussion to aspectj-dev as the questions are broader than the suggested weaver enhancement.But I disagree in the run-time weaving scenario.When you say "run-time" what do you mean. The proposed LTW design for JDK 1.4 does not support hot-code-replace as there is no interception point. Developers should use normal compile-time weaving with incremental compilation and Eclipse should automatically submit all the changed classes and aspects to the JVM being debugged. In 1.5 the java.lang.instrument API provides the opportunity to reweave HRC'd classes. However HCR for aspects is a different proposition which I haven't thought about yet!
Two thoughts that I have in mind: I played with hot code replacement (for various reasons) and there is one difficulty that I see when talking about runtime weaving for AspectJ done via HCR: Current VMs do not support "real" changes to the classes that are replaced (doesn't mapper if it is via the debug option of JDK 1.4 or the instrument package of JDK 1.5). Most VMs support only changes to the implementation of methods. You are not allowed to add or remove methods or static things (what you would need for AspectJ, I think). Only few VMs support new or removed methods for redefined classes. If you start to add fields to a class, I do not know of any VM that supports this kind of change to a class (even though the theory for this feature is well-known). Therefore I skipped any experiments to do run-time weaving for AspectJ using HCR. But I would be happy to hear if someone else got different results. What I do instead to play with "run-time-like" weaving for AspectJ is to enhance my AspectJ-enabled Eclipse Runtime to handle dynamic plugin behavior correctly. In my current implementation the runtime uses load-time weaving for plugins to weave existing aspects into the system. Plugins can define new aspects via an extension point of my enhanced runtime. When you think about dynamic plugins (as the are supported by the new OSGi-based runtime of Eclipse 3.0) you could think of plugins being installed and uninstalled at runtime. The Eclipse runtime handles this correctly. So what I am trying is to let my enhanced runtime react to those install/uninstall events correctly. This way you can install/uninstall aspects at runtime without closing the application and have a real "unweaving" at runtime. Sounds a bit tricky and I am not sure whether this will work for all possibilities of the AspectJ language but let me try. ;-) Therefore I remove aspects from an existing weaver.
BTW 1: How does the incremental compilation deal with deleted aspects?My understanding is that when an aspect is added, modified or removed everything is rewoven thereby preserving the invariant.
Ah, okay. No magic here. ;-)
BTW 2: You can achieve the same effect (that the removeLibraryAspectmethodwould provide) via World.getCrosscuttingMembersSet().deleteAspect(..).That method is only called once during BcelWeaving construction. Mutation is not supported.
But it seems to work. ;-) Okay, haven't tried too many things with this stuff. Are there any obvious things were the removal could cause problems with the internal weaver structures? -Martin
Matthew Webster AOSD Project Java Technology Centre, MP146 IBM Hursley Park, Winchester, SO21 2JN, England Telephone: +44 196 2816139 (external) 246139 (internal) Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx http://w3.hursley.ibm.com/~websterm/ bugzilla-daemon@xxxxxxxxxxx on 20/03/2004 14:14:12 To: Matthew Webster/UK/IBM@IBMGB cc: Subject: [Bug 55107] add removeLibraryAspect method to weaver https://bugs.eclipse.org/bugs/show_bug.cgi?id=55107 ------- Additional Comments From lippert@xxxxxxx 2004-03-20 09:14 ------- I see this from a different point of view. I agree to your objection regarding the weaving class loader and the typical load-time weaving scenario described in bug #31460. Therefore you should not remove any aspects while the load-time weaving class loader is active. But I disagree in the run-time weaving scenario. Of course you have to be careful with already loaded classes, reloading, and so on. But if you take care of the different situations and handle then in the right way, the removeLibraryAspect method would just prevent you from creating a new weaver instance. BTW 1: How does the incremental compilation deal with deleted aspects? BTW 2: You can achieve the same effect (that the removeLibraryAspect method would provide) via World.getCrosscuttingMembersSet().deleteAspect(..). ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ aspectj-dev mailing list aspectj-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/aspectj-dev
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature