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
