I'll keep this in mind the next time I'm going through this code ...
for the moment I prefer not to fix what isn't broken ;)
On 06 Nov 2007, at 17:53, Eugene Kuleshov wrote:
>
> Actually, you guys should use new Remapping* classes from ASM 3.1.
>
> Then you can write something like this:
>
> public class MergeAdapter extends ClassAdapter {
> private ClassNode cn;
> private String cname;
>
> public MergeAdapter(ClassVisitor cv, ClassNode cn) {
> super(cv);
> this.cn = cn;
> }
>
> public void visit(int version, int access, String name, String
> signature,
> String superName, String[] interfaces) {
> super.visit(version, access, name, signature, superName,
> interfaces);
> this.cname = name;
> }
>
> public void visitEnd() {
> for (Iterator it = cn.fields.iterator(); it.hasNext();) {
> ((FieldNode) it.next()).accept(this);
> }
> for (Iterator it = cn.methods.iterator(); it.hasNext();) {
> MethodNode mn = (MethodNode) it.next();
> String[] exceptions = new String[mn.exceptions.size()];
> mn.exceptions.toArray(exceptions);
> MethodVisitor mv = cv.visitMethod(mn.access, mn.name, mn.desc,
> mn.signature, exceptions);
> mn.instructions.resetLabels();
> mn.accept(new RemappingMethodAdapter(mn.access, mn.desc, mv, new
> Remapper(cname, cn.name)));
> }
> super.visitEnd();
> }
> }
>
> regards,
> Eugene
>
>
> Saravanan Subbiah wrote:
>> Cool ! Did you also change HashtableTC and HashMapTC to use this
>> instead
>> ? 'coz that will be sexy ;)
>>
>> Geert Bevin wrote:
>>
>>> Hi,
>>>
>>> just telling you all about a small change I did to
>>> MergeTCToJavaClassAdapter.
>>>
>>> It will now not merge abstract methods of the TC classes into the
>>> original classes. So for instance, any abstract method in
>>> ConcurrentHashMapTC will not be merged into ConcurrentHashMap.
>>> Before, this would always be the case, overriding any concrete
>>> methods in ConcurrentHashMap.
>>>
>>> This is quite useful when you have a mixed instrumentation scenario,
>>> like for ConcurrentHashMap where there are custom adaptors and a
>>> sibling FooTC class with as much clean Java code as possible. This
>>> allows the FooTC class to declare methods that are actually created
>>> in the base Foo class through instrumentation in a custom adaptor,
>>> for instance an original uninstrumented method implementation
>>> under a
>>> new name. Since these methods are now declared in the FooTC class,
>>> the clean Java code can use them and thus interact with the
>>> synthetic
>>> byte-code generated methods.
>>>
>>> Beforehand, the only way that I could find to do this was to
>>> introduce a bridge interface API. I think it's cleaner and more
>>> productive to not have to do that anymore.
>>>
>>> Take care,
>>>
>>> Geert
>>>
>>> --
>>> Geert Bevin
>>> Terracotta - http://www.terracotta.org
>>> Uwyn "Use what you need" - http://uwyn.com
>>> RIFE Java application framework - http://rifers.org
>>> Music and words - http://gbevin.com
>>>
>>> _______________________________________________
>>> tc-dev mailing list
>>> [email protected]
>>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>>
>>>
>>
>> _______________________________________________
>> tc-dev mailing list
>> [email protected]
>> http://lists.terracotta.org/mailman/listinfo/tc-dev
>>
>
> _______________________________________________
> tc-dev mailing list
> [email protected]
> http://lists.terracotta.org/mailman/listinfo/tc-dev
--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
tc-dev mailing list
[email protected]
http://lists.terracotta.org/mailman/listinfo/tc-dev
