IBM JDK JVMTI对redefineclass的增强

最近有同事在实现Harmony的instrument包，用到了IBM VME的jvmti，发现该jvmti实现的redefineclass方法严重"违反"specification的"bug"，并且IBM JDK 5也有同样的表现。大家都知道instrument允许应用程序在runtime动态修改class在内存中的bytecode，这是java 5的一个重要增强，这个feature是通过jvmti实现的，但是jvmti目前对此还有很多的限制，Java 5 JVMTI的文档对redefineclass方法有这样的固定:

" The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, change modifiers, or change inheritance. These restrictions may be lifted in future versions. "

如果应用试图做这些被禁止的操作，会得到一个UnsupportedOperationException，这一点对于我手头的Java 6 rc b65版本也依然成立(是老了点...可怜可怜下载Sun JDK需要approval的可怜人吧...)。但是在IBM JDK里面，这个限制是不存在的，也就是说，你可以在runtime任意修改class的bytecode， 增删改方法signature和field都可以(还没试过更改继承结构，不过想来也是可以的)，尽管有很多AOP框架可以做这个事情，但是原理上JVM直接提供的支持效率会好很多(还没有测试过，有空对比一下AspectJ)，脑子里立刻浮现出无数很cool的应用吧，嘿嘿。为了确认这是个有意为之的增强，我还专门到J9的内部站点上raise了一个bug，结果得到的答复果然是: 这是一个intended value add。后来又私下了解了一下，才知道hot code swapping是J9的一个重要卖点，但是奇怪的是为什么JavaOne2006上有关IBM JDK的presentation并没有提到这一点呢？呵呵。

对了，如果要禁止这个增强，也就是说得到遵守specification的行为，可以在启动JVM的使用加上-Xfuture参数，诡异，难道不应该叫-Xnofuture么? ;-)

Update: 犯乐观主义错误了，测试过了，更改类继承结构是不行的...:(