| Re: [aspectj-dev] Re: [Bug 55107] add removeLibraryAspect method to weaver |
Hi,
Maybe we should create something like a TypeInformationProvider interface which contains methods for getting the complete bytecode for a specific type as well as a faster method for getting the Class object for a specific type. Then the weaver could use the getClass method whenever possible and getBytecode method if he needs the complete bytecode (maybe if the Class object is not yet available).That sounds like a good idea. We should start by implemementing a provider architecture in the compiler: where you have modified the call to "lookupJavaClass()" in BcelWorld is the place. Basically we need our own implementation of ResolvedTypeX.ConcreteName (returned by " resolveObjectType()") which has methods like "getDeclaredFields()" that could use Java reflection. A WeavingAdaptor would automatically register a new provider with its World. We should not have to load byte-code during LTW as a call to "Class.forName()" to reslove a class will automatically cause the class loader to load the byte-code for us. Then we just have the issue of weaver re-entrancy to deal with for classed resolved by a weaving class loader!
I am not sure for that types we could use the Class object directly. If I remember it correctly the ConcreteName provides also aspect specific information that cannot be extracted from a Class object. Do we need this information in the LTW case? But we could use it at least for classes that are not part of LTW, like the original java.. and javax.. classes. (In those cases we would also not have any problem with re-entrancy.)
What do you think? -Martin
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature