xmlrpc.execute("ChatService.validateUser",params);
execute方法是xml-rpc client执行远程调用的方法。
第一个参数是方法名，第二个是这个远程方法的参数，用Vector传递。
基本上就是这样一个流程。一点都不复杂，有什么不明白的就给我发信，欢迎讨论。
源码下载：http://www.blogjava.net/Files/mstar/AppletRPC.rar
项目是用JBuilder2006做的，不知道以前版本的JBuilder能不能打开啊。

动态代理工具 是 java.lang.reflect 包的一部分，在 JDK 1.3 版本中添加到 JDK，它允许程序创建 代理对象，代理对象能实现一个或多个已知接口，并用反射代替内置的虚方法分派，编程地分派对接口方法的调用。这个过程允许实现“截取”方法调用，重新路由它们或者动态地添加功能。本期文章中，Brian Goetz 介绍了几个用于动态代理的应用程序。请在本文伴随的 讨论论坛 上与作者和其他读者分享您对这篇文章的想法。（也可以单击文章顶部或底部的 讨论 访问讨论论坛。）

动态代理为实现许多常见设计模式（包括 Facade、Bridge、Interceptor、Decorator、Proxy（包括远程和虚拟代理）和 Adapter 模式）提供了替代的动态机制。虽然这些模式不使用动态代理，只用普通的类就能够实现，但是在许多情况下，动态代理方式更方便、更紧凑，可以清除许多手写或生成的类。

Proxy 模式

Proxy 模式中要创建“stub”或“surrogate”对象，它们的目的是接受请求并把请求转发到实际执行工作的其他对象。远程方法调用（RMI）利用 Proxy 模式，使得在其他 JVM 中执行的对象就像本地对象一样；企业 JavaBeans （EJB）利用 Proxy 模式添加远程调用、安全性和事务分界；而 JAX-RPC Web 服务则用 Proxy 模式让远程服务表现得像本地对象一样。在每一种情况中，潜在的远程对象的行为是由接口定义的，而接口本质上接受多种实现。调用者（在大多数情况下）不能区分出它们只是持有一个对 stub 而不是实际对象的引用，因为二者实现了相同的接口；stub 的工作是查找实际的对象、封送参数、把参数发送给实际对象、解除封送返回值、把返回值返回给调用者。代理可以用来提供远程控制（就像在 RMI、EJB 和 JAX-RPC 中那样），用安全性策略包装对象（EJB）、为昂贵的对象（EJB 实体 Bean）提供惰性装入，或者添加检测工具（例如日志记录）。

在 5.0 以前的 JDK 中，RMI stub（以及它对等的 skeleton）是在编译时由 RMI 编译器（rmic）生成的类，RMI 编译器是 JDK 工具集的一部分。对于每个远程接口，都会生成一个 stub（代理）类，它代表远程对象，还生成一个 skeleton 对象，它在远程 JVM 中做与 stub 相反的工作 —— 解除封送参数并调用实际的对象。类似地，用于 Web 服务的 JAX-RPC 工具也为远程 Web 服务生成代理类，从而使远程 Web 服务看起来就像本地对象一样。

不管 stub 类是以源代码还是以字节码生成的，代码生成仍然会向编译过程添加一些额外步骤，而且因为命名相似的类的泛滥，会带来意义模糊的可能性。另一方面，动态代理机制支持在编译时没有生成 stub 类的情况下，在运行时创建代理对象。在 JDK 5.0 及以后版本中，RMI 工具使用动态代理代替了生成的 stub，结果 RMI 变得更容易使用。许多 J2EE 容器也使用动态代理来实现 EJB。EJB 技术严重地依靠使用拦截（interception）来实现安全性和事务分界；动态代理为接口上调用的所有方法提供了集中的控制流程路径。

回页首

动态代理机制

动态代理机制的核心是 InvocationHandler 接口，如清单 1 所示。调用句柄的工作是代表动态代理实际执行所请求的方法调用。传递给调用句柄一个 Method 对象（从 java.lang.reflect 包），参数列表则传递给方法；在最简单的情况下，可能仅仅是调用反射性的方法 Method.invoke() 并返回结果。

清单 1. InvocationHandler 接口

public interface InvocationHandler { Object invoke(Object proxy, Method method, Object[] args) throws Throwable; }

每个代理都有一个与之关联的调用句柄，只要代理的方法被调用时就会调用该句柄。根据通用的设计原则：接口定义类型、类定义实现，代理对象可以实现一个或多个接口，但是不能实现类。因为代理类没有可以访问的名称，它们不能有构造函数，所以它们必须由工厂创建。清单 2 显示了动态代理的最简单的可能实现，它实现 Set 接口并把所有 Set 方法（以及所有 Object 方法）分派给封装的 Set 实例。

清单 2. 包装 Set 的简单的动态代理

public class SetProxyFactory { public static Set getSetProxy(final Set s) { return (Set) Proxy.newProxyInstance (s.getClass().getClassLoader(), new Class[] { Set.class }, new InvocationHandler() { public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return method.invoke(s, args); } }); } }

SetProxyFactory 类包含一个静态工厂方法 getSetProxy()，它返回一个实现了 Set 的动态代理。代理对象实际实现 Set —— 调用者无法区分（除非通过反射）返回的对象是动态代理。SetProxyFactory 返回的代理只做一件事，把方法分派给传递给工厂方法的 Set 实例。虽然反射代码通常比较难读，但是这里的内容很少，跟上控制流程并不难 —— 只要某个方法在 Set 代理上被调用，它就被分派给调用句柄，调用句柄只是反射地调用底层包装的对象上的目标方法。当然，绝对什么都不做的代理可能有点傻，是不是呢？

什么都不做的适配器

对于像 SetProxyFactory 这样什么都不做的包装器来说，实际有个很好的应用 —— 可以用它安全地把对象引用的范围缩小到特定接口（或接口集）上，方式是，调用者不能提升引用的类型，使得可以更安全地把对象引用传递给不受信任的代码（例如插件或回调）。清单 3 包含一组类定义，实现了典型的回调场景。从中会看到动态代理可以更方便地替代通常用手工（或用 IDE 提供的代码生成向导）实现的 Adapter 模式。

清单 3. 典型的回调场景

public interface ServiceCallback { public void doCallback(); } public interface Service { public void serviceMethod(ServiceCallback callback); } public class ServiceConsumer implements ServiceCallback { private Service service; ... public void someMethod() { ... service.serviceMethod(this); } }

ServiceConsumer 类实现了 ServiceCallback（这通常是支持回调的一个方便途径）并把 this 引用传递给 serviceMethod() 作为回调引用。这种方法的问题是没有机制可以阻止 Service 实现把 ServiceCallback 提升为 ServiceConsumer，并调用 ServiceConsumer 不希望 Service 调用的方法。有时对这个风险并不关心 —— 但有时却关心。如果关心，那么可以把回调对象作为内部类，或者编写一个什么都不做的适配器类（请参阅清单 4 中的 ServiceCallbackAdapter）并用 ServiceCallbackAdapter 包装 ServiceConsumer。ServiceCallbackAdapter 防止 Service 把 ServiceCallback 提升为 ServiceConsumer。

清单 4. 用于安全地把对象限制在一个接口上以便不被恶意代码不能的适配器类

public class ServiceCallbackAdapter implements ServiceCallback { private final ServiceCallback cb; public ServiceCallbackAdapter(ServiceCallback cb) { this.cb = cb; } public void doCallback() { cb.doCallback(); } }

编写 ServiceCallbackAdapter 这样的适配器类简单却乏味。必须为包装的接口中的每个方法编写重定向类。在 ServiceCallback 的示例中，只有一个需要实现的方法，但是某些接口，例如 Collections 或 JDBC 接口，则包含许多方法。现代的 IDE 提供了“Delegate Methods”向导，降低了编写适配器类的工作量，但是仍然必须为每个想要包装的接口编写一个适配器类，而且对于只包含生成的代码的类，也有一些让人不满意的地方。看起来应当有一种方式可以更紧凑地表示“什么也不做的限制适配器模式”。

通用适配器类

清单 2 中的 SetProxyFactory 类当然比用于 Set 的等价的适配器类更紧凑，但是它仍然只适用于一个接口：Set。但是通过使用泛型，可以容易地创建通用的代理工厂，由它为任何接口做同样的工作，如清单 5 所示。它几乎与 SetProxyFactory 相同，但是可以适用于任何接口。现在再也不用编写限制适配器类了！如果想创建代理对象安全地把对象限制在接口 T，只要调用 getProxy(T.class,object) 就可以了，不需要一堆适配器类的额外累赘。

清单 5. 通用的限制适配器工厂类

public class GenericProxyFactory { public static<T> T getProxy(Class<T> intf, final T obj) { return (T) Proxy.newProxyInstance(obj.getClass().getClassLoader(), new Class[] { intf }, new InvocationHandler() { public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return method.invoke(obj, args); } }); } }

回页首

动态代理作为 Decorator

当然，动态代理工具能做的，远不仅仅是把对象类型限制在特定接口上。从 清单 2 和 清单 5 中简单的限制适配器到 Decorator 模式，是一个小的飞跃，在 Decorator 模式中，代理用额外的功能（例如安全检测或日志记录）包装调用。清单 6 显示了一个日志 InvocationHandler，它在调用目标对象上的方法之外，还写入一条日志信息，显示被调用的方法、传递的参数，以及返回值。除了反射性的 invoke() 调用之外，这里的全部代码只是生成调试信息的一部分 —— 还不是太多。代理工厂方法的代码几乎与 GenericProxyFactory 相同，区别在于它使用的是 LoggingInvocationHandler 而不是匿名的调用句柄。

清单 6. 基于代理的 Decorator，为每个方法调用生成调试日志

private static class LoggingInvocationHandler<T> implements InvocationHandler { final T underlying; public LoggingHandler(T underlying) { this.underlying = underlying; } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { StringBuffer sb = new StringBuffer(); sb.append(method.getName()); sb.append("("); for (int i=0; args != null && i<args.length; i++) { if (i != 0) sb.append(", "); sb.append(args[i]); } sb.append(")"); Object ret = method.invoke(underlying, args); if (ret != null) { sb.append(" -> "); sb.append(ret); } System.out.println(sb); return ret; } }

如果用日志代理包装 HashSet，并执行下面这个简单的测试程序：

Set s = newLoggingProxy(Set.class, new HashSet()); s.add("three"); if (!s.contains("four")) s.add("four"); System.out.println(s);

会得到以下输出：

add(three) -> true contains(four) -> false add(four) -> true toString() -> [four, three] [four, three]

这种方式是给对象添加调试包装器的一种好的而且容易的方式。它当然比生成代理类并手工创建大量 println() 语句容易得多（也更通用）。我进一步改进了这一方法；不必无条件地生成调试输出，相反，代理可以查询动态配置存储（从配置文件初始化，可以由 JMX MBean 动态修改），确定是否需要生成调试语句，甚至可能在逐个类或逐个实例的基础上进行。

在这一点上，我认为读者中的 AOP 爱好者们几乎要跳出来说“这正是 AOP 擅长的啊！”是的，但是解决问题的方法不止一种 —— 仅仅因为某项技术能解决某个问题，并不意味着它就是最好的解决方案。在任何情况下，动态代理方式都有完全在“纯 Java”范围内工作的优势，不是每个公司都用（或应当用） AOP 的。

动态代理作为适配器

代理也可以用作真正的适配器，提供了对象的一个视图，导出与底层对象实现的接口不同的接口。调用句柄不需要把每个方法调用都分派给相同的底层对象；它可以检查名称，并把不同的方法分派给不同的对象。例如，假设有一组表示持久实体（Person、Company 和 PurchaseOrder） 的 JavaBean 接口，指定了属性的 getter 和 setter，而且正在编写一个持久层，把数据库记录映射到实现这些接口的对象上。现在不用为每个接口编写或生成类，可以只用一个 JavaBean 风格的通用代理类，把属性保存在 Map 中。

清单 7 显示的动态代理检查被调用方法的名称，并通过查询或修改属性图直接实现 getter 和 setter 方法。现在，这一个代理类就能实现多个 JavaBean 风格接口的对象。

清单 7. 用于把 getter 和 setter 分派给 Map 的动态代理类

public class JavaBeanProxyFactory { private static class JavaBeanProxy implements InvocationHandler { Map<String, Object> properties = new HashMap<String, Object>(); public JavaBeanProxy(Map<String, Object> properties) { this.properties.putAll(properties); } public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { String meth = method.getName(); if (meth.startsWith("get")) { String prop = meth.substring(3); Object o = properties.get(prop); if (o != null && !method.getReturnType().isInstance(o)) throw new ClassCastException(o.getClass().getName() + " is not a " + method.getReturnType().getName()); return o; } else if (meth.startsWith("set")) { // Dispatch setters similarly } else if (meth.startsWith("is")) { // Alternate version of get for boolean properties } else { // Can dispatch non get/set/is methods as desired } } } public static<T> T getProxy(Class<T> intf, Map<String, Object> values) { return (T) Proxy.newProxyInstance (JavaBeanProxyFactory.class.getClassLoader(), new Class[] { intf }, new JavaBeanProxy(values)); } }

虽然因为反射在 Object 上工作会有潜在的类型安全性上的损失，但是，JavaBeanProxyFactory 中的 getter 处理会进行一些必要的额外的类型检测，就像我在这里用 isInstance() 对 getter 进行的检测一样。

回页首

性能成本

正如已经看到的，动态代理拥有简化大量代码的潜力 —— 不仅能替代许多生成的代码，而且一个代理类还能代替多个手写的类或生成的代码。什么是成本呢？ 因为反射地分派方法而不是采用内置的虚方法分派，可能有一些性能上的成本。在早期的 JDK 中，反射的性能很差（就像早期 JDK 中几乎其他每件事的性能一样），但是在近 10 年，反射已经变得快多了。

不必进入基准测试构造的主题，我编写了一个简单的、不太科学的测试程序，它循环地把数据填充到 Set，随机地对 Set进行插入、查询和删除元素。我用三个 Set 实现运行它：一个未经修饰的 HashSet，一个手写的、只是把所有方法转发到底层的 HashSet 的 Set 适配器，还有一个基于代理的、也只是把所有方法转发到底层 HashSet 的 Set 适配器。每次循环迭代都生成若干随机数，并执行一个或多个 Set 操作。手写的适配器比起原始的 HashSet 只产生很少百分比的性能负荷（大概是因为 JVM 级有效的内联缓冲和硬件级的分支预测）；代理适配器则明显比原始 HashSet 慢，但是开销要少于两个量级。

我从这个试验得出的结论是：对于大多数情况，代理方式即使对轻量级方法也执行得足够好，而随着被代理的操作变得越来越重量级（例如远程方法调用，或者使用序列化、执行 IO 或者从数据库检索数据的方法），代理开销就会有效地接近于 0。当然也存在一些代理方式的性能开销无法接受的情况，但是这些通常只是少数情况。

Dennis Sosnoski
主席, Sosnoski Software Solutions, Inc.
2005 年 7 月 25 日

许多 J2SE 5.0 语言特性应该对旧版 JVM 也有用，但是实现这些特性的编译器会生成需要 JDK 5.0 或更高版本的代码。幸运的是，有一个开放源代码项目 Retroweaver 在 J2SE 5.0 与旧版 JVM 之间架起了一座桥梁。Retroweaver 转换您的类文件以消除 JDK 5.0 依赖性，同时添加其自己的支持函数库以使得大多数 5.0 特性在旧版 JVM 上完全有用。如果您喜欢 J2SE 5.0 语言特性，却无法在运行时使用 JDK 5.0，那么 Retroweaver 就是您所需要的。

J2SE 5.0 为 Java 语言带来了巨大的改变，因此即使是经验丰富的 Java 开发人员也需要深入的培训才能利用 5.0 特性。不幸的是，实现这些语言特性的 JDK 5.0 编译器在生成特定于 JDK 5.0 或更高版本的代码时不支持这些特性。如果试图在早期的 JVM 上运行生成的代码，将会得到 java.lang.UnsupportedClassVersionError 错误。

即使生成的类指定 JDK 5.0 和更高的 JVM，但是故事并没有结束。开发人员发现，一些新特性实际上生成与旧版 JVM 完全兼容的代码，而其他特性可以与标准库的少量扩展兼容。有一个名叫 Toby Reyelts 的开发人员决定消除 JDK 5.0 编译器限制。结果就是开放源代码的 Retroweaver 项目（参见 参考资料）。Retroweaver 使用 classworking 技术来修改由 JDK 5.0 编译器生成的二进制类表示，以便这些类可以与早期的 JVM 一起使用。

对于本文来说，我将展示 Retroweaver 的基本使用。Retroweaver 实际上非常容易使用，所以不用花太大的篇幅去介绍它，所以我还将修改 上个月 介绍的 annotations+ASM 运行时代码生成方法以使用 5.0 之前的 JDK，期间使用了 Retroweaver 来回避 JDK 5.0 编译器限制。

向后兼容 J2SE 5.0
Retroweaver 包含两个逻辑组件：一个字节码增强器和一个运行时库。字节码增强器使用 classworking 技术来修改由 JDK 5.0 编译器生成的类文件，使得这些类可以用于旧版 JVM。作为类文件修改的一部分，Retroweaver 可能需要替换对添加到 J2SE 5.0 中的标准类的引用。实际的替换类包含在运行时库中，以便在您执行修改过的代码时它们是可用的。

按照标准开发周期来说，字节码增强器需要在 Java 代码编译之后、类文件为部署而打包之前运行。在您使用一个 IDE 时，该更改是一个问题 ——“集成”一个类转换工具到“开发环境”是很痛苦的事情，因为 IDE 一般假设它们拥有类文件。限制这一痛苦的一种方式是，只对 IDE 中的大多数测试使用 JDK 5.0。这样，您只需要在想要为部署打包文件或者想要测试实际的部署 JVM 时转换类文件。如果使用 Ant 风格的构建过程，就没有问题；只添加 Retroweaver 字节码增强器作为编译之后的一个步骤。

Retroweaver 具有一个小小的限制：尽管 Retroweaver 允许您在运行在旧版 JVM 上的代码中使用 J2SE 5.0 语言特性，但是它并不支持也包含在 J2SE 5.0 中的所有添加到标准 Java 类的特性。如果您的代码使用任何添加到 J2SE 5.0 中的类或方法，那么就将在试图加载旧版 JVM 中的代码时得到错误，哪怕是在 Retroweaver 处理完成之后也如此。避免对标准库的 J2SE 5.0 添加不应该是一个主要问题，但是如果使用 IDE 中的感应弹出特性并偶然挑选了一个仅添加到 J2SE 5.0 中的方法或类，它就有可能让您得到错误。

它做什么
J2SE 5.0 的更改既发生在 JVM 中，也发生在实际的 Java 语言，但是 JVM 更改相当小。有一个新的字符可以用于字节码中的标识符中 ("+")，一些处理类引用的指令发生了修改，还有一个不同的方法用于处理合成组件。 Retroweaver 在字节码增强步骤中处理这些 JVM 更改，方法是把这些更改返回原样，即替换成用于 J2SE 5.0 之前相同目的的方法（比如标识符中的 + 字符，就是用 $ 取代它）。

包含在 J2SE 5.0 中的语言更改要稍微复杂一点。一些最有趣的更改，比如增强的 for 循环，基本上只是语法更改，即为表示编程操作提供快捷方式。比如泛型更改 —— 泛型类型信息 —— 由编译器用于实施编译时安全，但是生成的字节码仍然到处使用强制转换。但是大多数更改使用了添加到核心 Java API 中的类或方法，所以您不能直接使用为 JDK 5.0 生成的字节码并将它直接运行在早期的 JVM 上。Retroweaver 为支持 J2SE 5.0 语言更改所需的新类提供其自己的等价物，并且用对其自己的类的引用替换对标准类的引用，这是字节码增强步骤的一部分。

Retroweaver 字节码增强不能对所有的 J2SE 5.0 语言更改提供完全支持。例如，没有对处理注释的运行时支持，因为运行时支持涉及到对基本 JVM 类加载器实现的更改。但是一般来说，只是不支持那些不会影响普通用户的小特性。

Retroweaver 发挥作用
使用 Retroweaver 简直是太容易了。可以使用一个简单的 GUI 界面或者控制台应用程序来在应用程序类文件上运行字节码增强。两种方式都只要在将要转换的类文件树的根目录指出 Retroweaver 即可。在运行时，如果使用任何需要运行时支持的特性（比如 enums），那么就需要在类路径中包含 Retroweaver 运行时 jar。

清单 1 给出了一个简单的示例程序，其中使用了一些 J2SE 5.0 特性。com.sosnoski.dwct.Primitive 是一个针对 Java 语言原语类型的 enum 类。main() 方法使用增强的 for 循环来迭代通过不同的原语，并在当前实例上使用一个简单的 switch 语句来设置每个原语的大小值。

package com.sosnoski.dwct;

public enum Primitive
{
    BOOLEAN, BYTE, CHARACTER, DOUBLE, FLOAT, INT, LONG, SHORT;
    
    public static void main(String[] args) {
        for (Primitive p : Primitive.values()) {
            int size = -1;
            switch (p) {
                case BOOLEAN:
                case BYTE:
                    size = 1;
                    break;
                case CHARACTER:
                case SHORT:
                    size = 2;
                    break;
                case FLOAT:
                case INT:
                    size = 4;
                    break;
                case DOUBLE:
                case LONG:
                    size = 8;
                    break;
            }
            System.out.println(p + " is size " + size);
        }
    }
}

使用 JDK 5.0 编译并运行清单 1 代码会给出清单 2 中的输出。但是不能在早期的 JDK 下编译或运行清单 1 代码；由于特定于 J2SE 5.0 的特性会导致编译失败，而运行失败会抛出 java.lang.UnsupportedClassVersionError 异常。

[dennis@notebook code]$ java -cp classes com.sosnoski.dwct.Primitive
BOOLEAN is size 1
BYTE is size 1
CHARACTER is size 2
DOUBLE is size 8
FLOAT is size 4
INT is size 4
LONG is size 8
SHORT is size 2

清单 3 展示了在 Primitive 类上运行 Retroweaver。这个类实际上编译为两个类文件，一个用于 enum 类，另一个支持在 switch 语句中使用 enum。（注意，清单代码换行是为了适应页面宽度。）

[dennis@notebook code]$ java -cp retro/release/retroweaver.jar:retro/lib/bcel-5.1.jar:retro/lib/
  jace.jar:retro/lib/Regex.jar com.rc.retroweaver.Weaver -source classes
[RetroWeaver] Weaving /home/dennis/writing/articles/devworks/series/may05/code/
  classes/com/sosnoski/dwct/Primitive$1.class
[RetroWeaver] Weaving /home/dennis/writing/articles/devworks/series/may05/code/
  classes/com/sosnoski/dwct/Primitive.class

在运行 Retroweaver 之后，这些类就可以用于 JDK 5.0 和 JDK 1.4 JVM 上了。当使用 1.4 JVM 运行修改后的类时，输出与 清单 2 中的相同。Retroweaver 提供命令行选项来指定旧的 1.3 和 1.2 JVM 以取代默认的 1.4 目标，但是我下载的运行时 jar 版本需要 1.4，我不想重新构建它以检查对早期 JVM 的支持。

JDK 1.4 上的注释
既然已经看到了 Retroweaver 如何让您运行在早期 JVM 上的同时在源代码中使用 J2SE 5.0 特性，我将返回到 上个月 的代码。以防您没有阅读上一期，我在此做一个总结：我展示了如何使用 ASM 2.0 基于注释实现运行时类转换，并给出一个注释的特定例子，该注释用于指定 toString() 方法中应该包括哪些字段。

上个月的代码只适用于 JDK 5.0 或更高版本。在本文中，我将修改代码以适用于早期 JVM。与 Retroweaver 一起使用，自动化 toString() 生成的好处将会扩展到许多还停留在 J2SE 5.0 之前运行时的 Java 开发人员。

回忆 ToStringAgent
我用于对 JDK 5.0 实现 toString() 方法生成的 com.sosnoski.asm.ToStringAgent 类对于旧版 JVM 有一个小小的问题：它使用 J2SE 5.0 中新增的 instrumentation API 来在运行时截取类加载和修改类。在早期 JVM 中截取类加载不太灵活，但是并不是不可能 —— 只需要用您自己的版本来取代用于应用程序的类加载器就可以了。由于所有的应用程序类都是通过您的自定义类加载器加载的，所以在它们被实际提供给 JVM 之前，您可以自由地修改类表示。

更新 上个月 的代码以使用自定义类加载器方法是很容易的。清单 4 展示了带有所有修改的类。该类取代了上一期文章中使用的 com.sosnoski.asm.ToStringAgent 类。上一期中使用到的其他类保持不变。

package com.sosnoski.asm;

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.Method;
import java.net.URL;
import java.net.URLClassLoader;

import org.objectweb.asm.ClassReader;
import org.objectweb.asm.ClassWriter;

public class ToStringLoader extends URLClassLoader
{
    private ToStringLoader(URL[] urls, ClassLoader parent) {
        super(urls, parent);
    }

    // override of ClassLoader method
    protected Class findClass(String name) throws ClassNotFoundException {
        String resname = name.replace('.', '/') + ".class";
        InputStream is = getResourceAsStream(resname);
        if (is == null) {
            System.err.println("Unable to load class " + name +
                " for annotation checking");
            return super.findClass(name);
        } else {
            System.out.println("Processing class " + name);
            try {
                
                // read the entire content into byte array
                ByteArrayOutputStream bos = new ByteArrayOutputStream();
                byte[] buff = new byte[1024];
                int length;
                while ((length = is.read(buff)) >= 0) {
                    bos.write(buff, 0, length);
                }
                byte[] bytes = bos.toByteArray();
                
                // scan class binary format to find fields for toString() method
                ClassReader creader = new ClassReader(bytes);
                FieldCollector visitor = new FieldCollector();
                creader.accept(visitor, true);
                FieldInfo[] fields = visitor.getFields();
                if (fields.length > 0) {
                    
                    // annotated fields present, generate the toString() method
                    System.out.println("Modifying " + name);
                    ClassWriter writer = new ClassWriter(false);
                    ToStringGenerator gen = new ToStringGenerator(writer,
                            name.replace('.', '/'), fields);
                    creader.accept(gen, false);
                    bytes = writer.toByteArray();
                }
                
                // return the (possibly modified) class
                return defineClass(bytes, 0, bytes.length);
                
            } catch (IOException e) {
                throw new ClassNotFoundException("Error reading class " + name);
            }
        }
    }

    public static void main(String[] args) {
        if (args.length >= 1) {
            try {
                
                // get paths to be used for loading
                ClassLoader base = ClassLoader.getSystemClassLoader();
                URL[] urls;
                if (base instanceof URLClassLoader) {
                    urls = ((URLClassLoader)base).getURLs();
                } else {
                    urls = new URL[] { new File(".").toURI().toURL() };
                }
                
                // load the target class using custom class loader
                ToStringLoader loader =
                    new ToStringLoader(urls, base.getParent());
                Class clas = loader.loadClass(args[0]);
                    
                // invoke the "main" method of the application class
                Class[] ptypes = new Class[] { args.getClass() };
                Method main = clas.getDeclaredMethod("main", ptypes);
                String[] pargs = new String[args.length-1];
                System.arraycopy(args, 1, pargs, 0, pargs.length);
                Thread.currentThread().setContextClassLoader(loader);
                main.invoke(null, new Object[] { pargs });
                
            } catch (Exception e) {
                e.printStackTrace();
            }
            
        } else {
            System.out.println("Usage: com.sosnoski.asm.ToStringLoader " +
                "report-class main-class args...");
        }
    }
}

为了使用清单 4 代码，我仍然需要使用 JDK 5.0 编译与注释相关的代码，然后在产生的类集合上运行 Retroweaver。我也需要在类路径中包含 retroweaver.jar 运行时代码（因为 Retroweaver 对已转换的注释使用它自己的类）。清单 5 展示了运行与 上个月 相同的测试代码所产生的输出，但是这一次使用了 Retroweaver 和清单 4 中的 ToStringLoader 类，其中命令行换行是为了适应页面宽度）。

[dennis@notebook code]$ java -cp classes:retro/release/retroweaver-rt.jar:lib/
  asm-2.0.RC1.jar:lib/asm-commons-2.0.RC1.jar
  com.sosnoski.asm.ToStringLoader com.sosnoski.dwct.Run
Processing class com.sosnoski.dwct.Run
Processing class com.sosnoski.dwct.Name
Modifying com.sosnoski.dwct.Name
Processing class com.sosnoski.dwct.Address
Modifying com.sosnoski.dwct.Address
Processing class com.sosnoski.dwct.Customer
Modifying com.sosnoski.dwct.Customer
Customer: #=12345
 Name: Dennis Michael Sosnoski
 Address: street=1234 5th St. city=Redmond state=WA zip=98052
 homePhone=425 555-1212 dayPhone=425 555-1213

清单 5 显示了生成的 toString() 方法的输出，其末尾部分与 上个月 代码的 JDK 5.0 版本的结果相同。被处理的类列表几乎是相同的，只是用于截取类加载的技术不同。用于 JDK 1.4 的自定义类加载器方法不提供 JDK 5.0 instrumentation API 的完全灵活性，但是它适用于所有最近的 JVM，并允许您修改任何应用程序类。

结束语
在本期文章中，我展示了如何使用 Retroweaver 来使 J2SE 5.0 Java 代码可运行在旧版 JVM 上。如果您喜欢新的 J2SE 5.0 语言特性，并迫不及待想在自己的应用程序中使用这些特性，那么 Retroweaver 提供了完美的解决方案：您可以马上在开发中开始使用这些语言特性，根本不会影响生产平台。作为 Retroweaver 发挥作用的一个例子，我也 backport 了 上个月 的基于注释的 ToString 生成器，以在早期 JVM 上运行。

对于下个月的文章，我将回到在上一期文章中简要提到的一个问题，即注释与外部配置文件之间的权衡。在配置文件疯狂了很多年之后，整个的 Java 扩展集合似乎都一股脑儿转向使用注释了。但是难道注释总是提供配置类型信息的最佳方式吗？我对此表示怀疑，下个月我将提供一些例子，以及一些我个人的最佳实践指导方针。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• 单击本文顶部或底部的 代码 图标，下载文中讨论的源代码。
  
  
• 想要开始在旧版 JVM 上使用 J2SE 5.0 语言特性？请直接查看 Retroweaver 项目 的开放源代码。
  
  
• 获得 ASM 这个快速而灵活的 Java 字节码操作框架的所有详细资料。
  
  
• 对 J2SE 5.0 与旧版 Java 平台的区别感兴趣？请查看 John Zukowski 撰写的 驯服 Tiger 系列，了解所有的更改。
  
  
• 在 JSR-175: A Metadata Facility for the Java Programming Language 中找到关于 J2SE 注释的所有信息。
  
  
• 关于使用自定义类加载器在运行时进行类转换的深入讨论，请参阅作者的文章“Java 编程的动态性，第 5 部分: 动态转换类”（developerWorks, 2004 年 2 月）。
  
  
• 不要错过 Dennis Sosnoski 撰写的 Classworking 工具箱 系列中的其他文章。
  
  
• 请参阅 Peter Haggar 撰写的“Java bytecode: Understanding bytecode makes you a better programmer”（developerWorks, 2001 年 7 月），了解关于 Java 字节码设计的更多信息。
  
  
• 同样由 Dennis Sosnoski 撰写的 Java 编程的动态性 系列，将带您漫游 Java 类结构、发射和 classworking。
  
  
• Jikes 开放源代码项目提供了 Java 编程语言的非常快速和高兼容性的编译器。可以使用它来老式地生成字节码 —— 从 Java 源代码生成。
  
  
• 要了解更多关于 Java 技术的信息，请访问 developerWorks Java 专区。您将找到技术文档、how-to 文章、教程、下载、产品信息，以及更多内容。
  
  
• 请访问 New to Java technology 站点，找到帮助您开始 Java 编程的最新资源。
  
  
• 通过参与 developerWorks blogs 加入 developerWorks 社区。
  

June 22, 2005

Much has already been much written and discussed concerning the upcoming changes to Enterprise JavaBeans (EJB) with the proposed 3.0 specification. The simplifications of the component model and metadata configuration will definitely make this update an important evolution of J2EE. One of the most significant changes within EJB 3.0 is the new persistence model. This new persistence API and approach to modeling is based on the success of leading object-relational mapping products that use a Plain Old Java Object (POJO) approach to persistence.

We'll look into EJB 3.0 persistence and address the concerns of enterprise application developers and architects who are currently using EJB 2.1 CMP. The process of moving from EJB 2.1 persistence to EJB 3.0 can range from coexistence to a full migration and adoption of the new model. Although much has already been written about the new persistence model, specific strategies and development and design patterns have not been detailed. We'll attempt to fill these gaps with concrete solution options while visiting the key benefits that application developers will gain through this migration. We assume that you are familiar with the basic elements of the new persistence API. (Note: Look for an upcoming article on migrating J2EE applications to EJB 3.0 in Java Pro magazine by Debu Panda, a member of the Oracle Application Server Development team, that will post on FTPOnline in July, 2005.)

Why Migrate?
One question participants in J2EE projects should discuss when planning an upgrade to an EJB 3.0-enabled J2EE container is: Why should we migrate our application? These new EJB 3.0 containers will be backward compatible and thus support their existing application without modification. This backward compatibility means that upgrading a container to EJB 3.0 does not mean in itself that an application needs to be rewritten. However, what about this new persistence API?

SELECT NEW example.EmpView(
  e.id, e.firstName, e.lastName, 
  d.name)
FROM Employee e JOIN 
  e.department d 
WHERE e.salary > 50000