| Re: [aspectj-dev] Re: [Bug 55107] add removeLibraryAspect method to weaver |
>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! 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/ Martin Lippert <lippert@xxxxxxx>@eclipse.org on 05/04/2004 12:08:10 Please respond to aspectj-dev@xxxxxxxxxxx Sent by: aspectj-dev-admin@xxxxxxxxxxx To: aspectj-dev@xxxxxxxxxxx cc: Subject: Re: [aspectj-dev] Re: [Bug 55107] add removeLibraryAspect method to weaver Hi, >>That sounds like a great thing. Would that be possible with the current >>weaver implementation or do you need to reimplement parts of that >>because of the BCEL dependencies? > >>BTW: I am currently using a specialized version of BcelWorld which >>enhances the "lookupJavaClass" method. My implementation first calls the >>super class and then tries to load the bytecode of the class via >>getResource using the class loader. Using this mechamism I do not need >>to set the complete classpath to my BcelWorld (which would be quite >>complicated using the Eclipse 3.0 runtime model). What do you think >>about an interface for this class lookup? > > You are in the right ball park. An idea that I discussed briefly with Jim > was to create an implementation of ConcreteName that relies on information > from Java reflection. This will cut down on footprint, be quicker that > re-parsing byte-code and guarantee the correct type. However your approach > is an excellent first step. Can you send me a code snippet and I will try > to add it to 31460. The idea to improve the weaving performance this like sounds great! The code snippet I could send you depends on some Eclipse internal classes. Nevertheless I could send you that snippet, if you like. 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). In addition to that we could add a method to the WeavingAdaptor to set this kind of interface. That would make the WeavingAdaptor more flexible, I think. The weaving class loader could create a default implementation for the interface mentioned above that uses the ClasspathManager to load bytecode and a map of already loaded classes for the getClass method. What do you think? -Martin
Attachment:
smime.p7s
Description: Binary data