I'm working with the JBossRetro prototype Adrian checked in:
I haven't done any extra work on it, except wrapping it in an ant task - I just cloned Bill's AopC task.
It even uses itself, in that some of the code is Java5 but the generated jar contains code compatibile with Java1.4. :-)
Basic TODOs left in the source code
see also the JIRA task:
* Externalise the class mapping, e.g.
java.lang.StringBuilder -> java.lang.StringBuffer or better for JBoss java.lang.StringBuilder -> org.jboss.util.JBossStringBuilder
* Externalise the editor expressions:
e.g. like the one that came up yesterday
* Complete the LDC rewrite to cope with large constant pools i.e. LDC_W
To get the project:
cvs -d:ext:firstname.lastname@example.org:/cvsroot/jboss co jbossretro
The current Weaver.doWeave(ClassLoader, CompilerClassInfo, Map, ExprEditor) seems a broken because there is a usage of a javassist ClassFile representation and then an incomplete usage of the ExprEditors. The problem is that there is no bidirectional consistency between the CompilerClassInfo.ClassFile and CompilerClassInfo.CtClass as well as no writing of the ExprEditor instrument results. Even if there was a write of the ExprEditor instrument results, it seems that this would simply be overwriten by the class renaming and ConstantPool mods done on the ClassFile.
I saw that the CtClass updates were not be written out when I tried to add a CtClass.instrument(CodeConverter) for the new autoboxing utility method calls(java.lang.Integer.valueOf(int) mapped to a jboss AutoboxCodeConverter.valueOf(int) method for example).
It seems that we should only be dealing with the CtClass representation when performing modifications and then invoking CtClass.write(...) to commit the changes on return from doWeave. I'm putting together some tests to validate the basic functionality as currently there none and will be looking to make this change.