今天看了huihoo的JFoxMX 1.0

好像比MX4j 1.1.1的要简单，既然MX4j已经提供了http adaptor，还要重复开发干什么？我觉得可以基于新的NIO开发一个socketserver，供实时对速度要求高的系统使用。

HuiHoo 的 MX 实现是很早就提出的，那时我是还没听说过有 MX4J.
HuiHoo 是想按照 JBoss MX 的思路设计和实现。
不知道 MX4J 是不是也借鉴了 JBossMX 的实现。我专门去看过一些代码，两者都使用 BECL 来优化代码，提高性能

重复开发这个东东，很难说，因为有时作者是为了能完全控制代码的所有权，有时只是为了证明自己....

据说BCEL已经要整合到j2se1.5中去，我以前看过几次，不知、这东西对提高性能有好处。

iceant 兄：

你能谈谈如何使用BCEL来优化代码吗？

我试试说明吧，但是 JMX 规范看了有一段时间，有些细节记不清了。
我们知道 JMX 有两种 MBean,StandardMBean 和 DynamicMBean.
StandardMBean 需要开发者写 Interface 和 Implementation.
DynamicMBean 是通过一些手段动态发现Bean 的方法和属性.

SUN 的 JMX RI 1.0 使用的是 Reflect 来完成 DynamicMBean.
做为程序员，我想大多数人都喜欢使用 DynamicMBean. 这样简单，
不需要又写 Interface,又写 Implementation.
于是如何处理好 DynamicMBean 的管理就成了一种性能瓶颈。

之所以说 BCEL 的方法更有效，是它以直接写二进制代码的方式在生成 Proxy 类。
这比 JDK 中的 reflect 包的效率要高很多。
JBoss 有一份测试的前后报告，目的就是说明使用 BCEL 以后带来的性能有大幅提高.
并且这种做法，在 MX4J 中也得到了应用.

JBoss 采取将 StandardMBean 和 DynamicMBean 都看做 DynamicMBean 的方式
来进行统一管理.我认为，在从 StandardMBean 中获得取信息，生成 MBeanInfo 等接口
时肯定有一些性能损失.
另外,因为用 BCEL 来写Proxy实际上是很抽象的，要写一个很复杂的 Proxy 实现，比较困难
于是, JBoss 的 MX 有一些不足:
有些JMX 规范中的Inheritance模型，它不能支持，但是一般管理用的 Bean 不会那么复杂.
所以，这其实也不算什么问题.