| | | | | | | [文章信息] | | | 作者: | 陶刚编译 | | 时间: | 2004-12-24 | | 出处: | 天极网 | | 责任编辑: | 方舟 | |
| [文章导读] | | | 在本文中我将考虑使用嵌入GUI应用程序中的状态条组件的情形 | |
| |
|
| | | |
|
|
|
|
|
重构源代码
现在我的消息都被编码放入元数据中了，我必须编写一些代码来通知状态监听程序。假设在某个时候，我继续把connectToDB方法保存源代码控件中，但是却没有对StatusManager的任何引用。但是，在编译这个类之前，我希望加入一些必要的调用。也就是说，我希望自动地插入try-finally语句和push/pop调用。
XDoclet框架组件是一种Java源代码生成引擎，它使用了类似上述的注解，但是把它们存储在Java源代码的注释（comment）中。XDoclet生成整个Java类、配置文件或其它建立的部分的时候非常完美，但是它不支持对已有Java类的修改，而这限制了重构的有效性。作为代替，我可以使用分析工具（例如JavaCC或ANTLR，它提供了分析Java源代码的语法基础），但是这需要花费大量精力。
看起来没有什么可以用于Java代码的源代码重构的很好的工具。这类工具可能有市场，但是你在本文的后面部分可以看到，字节码重构可能是一种更强大的技术。 重构字节码
不是重构源代码然后编译它，而是编译原始的源代码，然后重构它所产生的字节码。这样的操作可能比源代码重构更容易，也可能更加复杂，而这依赖于需要的准确转换。字节码重构的主要优点是代码可以在运行时被修改，不需要使用编译器。
尽管Java的字节码格式相对简单，我还是希望使用一个Java类库来执行字节码的分析和生成（这可以把我们与未来Java类文件格式的改变隔离开来）。我选择了使用Jakarta的Byte Code Engineering Library（字节码引擎类库，BCEL），但是我还可以选用CGLIB、ASM或SERP。
由于我将使用多种不同的方式重构字节码，我将从声明重构的通用接口开始。它类似于执行基于注解重构的简单框架组件。这个框架组件基于注解，将支持类和方法的转换，因此该接口有类似下面的定义：
public interface Instrumentor
{
public void instrumentClass (ClassGen classGen,Annotation a);
public void instrumentMethod (ClassGen classGen,MethodGen methodGen,Annotation a);
} |
ClassGen和MethodGen都是BCEL类，它们使用了Builder模式（pattern）。也就是说，它们为改变其它不可变的（immutable）对象、以及可变的和不可变的表现（representation）之间的转换提供了方法。
现在我需要为接口编写实现，它必须用恰当的StatusManager调用更换@Status注解。前面提到，我希望把这些调用包含在try-finally代码块中。请注意，要达到这个目标，我们所使用的注解必须用@Retention(RetentionPolicy.CLASS)进行标记，它指示Java编译器在编译过程中不要抛弃注解。由于在前面我把@Status声明为@Retention(RetentionPolicy.SOURCE)的，我必须更新它。
在这种情况下，重构字节码明显比重构源代码更复杂。其原因在于try-finally是一种仅仅存在于源代码中的概念。Java编译器把try-finally代码块转换为一系列的try-catch代码块，并在每一个返回之前插入对finally代码块的调用。因此，为了把try-finally代码块添加到已有的字节码中，我也必须执行类似的事务。
下面是表现一个普通方法调用的字节码，它被StatusManager更新环绕着：
0: ldc #2; //字符串消息
2: invokestatic #3; //方法StatusManager.push:(LString;)V
5: invokestatic #4; //方法 doSomething:()V
8: invokestatic #5; //方法 StatusManager.pop:()V
11: return |
下面是相同的方法调用，但是位于try-finally代码块中，因此，如果它产生了异常会调用StatusManager.pop()：
0: ldc #2; //字符串消息
2: invokestatic #3; //方法 StatusManager.push:(LString;)V
5: invokestatic #4; //方法 doSomething:()V
8: invokestatic #5; //方法 StatusManager.pop:()V
11: goto 20
14: astore_0
15: invokestatic #5; //方法 StatusManager.pop:()V
18: aload_0
19: athrow
20: return
Exception table:
from to target type
5 8 14 any
14 15 14 any |
你可以发现，为了实现一个try-finally，我必须复制一些指令，并添加了几个跳转和异常表记录。幸运的是，BCEL的InstructionList类使这种工作相当简单。
在运行时重构字节码
现在我拥有了一个基于注解修改类的接口和该接口的具体实现了，下一步是编写调用它的实际框架组件。实际上我将编写少量的框架组件，先从运行时重构所有类的框架组件开始。由于这种操作会在build过程中发生，我决定为它定义一个Ant事务。build.xml文件中的重构目标的声明应该如下：
＜instrument class="com.pkg.OurInstrumentor"＞
＜fileset dir="$(classes.dir)"＞
＜include name="**/*.class"/＞
＜/fileset＞
＜/instrument＞ |
为了实现这种事务，我必须定义一个实现org.apache.tools.ant.Task接口的类。我们的事务的属性和子元素（sub-elements）都是通过set和add方法调用传递进来的。我们调用执行（execute）方法来实现事务所要执行的工作--在示例中，就是重构＜fileset＞中指定的类文件。
public class InstrumentTask extends Task {
...
public void setClass (String className) { ... }
public void addFileSet (FileSet fileSet) { ... }
public void execute () throws BuildException {
Instrumentor inst = getInstrumentor();
try {
DirectoryScanner ds =fileSet.getDirectoryScanner(project);
// Java 1.5 的"for" 语法
for (String file : ds.getIncludedFiles()) {
instrumentFile(inst, file);
}
} catch (Exception ex) {
throw new BuildException(ex);
}
}
...
} |
用于该项操作的BCEL 5.1版本有一个问题--它不支持分析注解。我可以载入正在重构的类并使用反射（reflection）查看注解。但是，如果这样，我就不得不使用RetentionPolicy.RUNTIME来代替RetentionPolicy.CLASS。我还必须在这些类中执行一些静态的初始化，而这些操作可能载入本地类库或引入其它的依赖关系。幸运的是，BCEL提供了一种插件（plugin）机制，它允许客户端分析字节码属性。我编写了自己的AttributeReader的实现（implementation），在出现注解的时候，它知道如何分析插入字节码中的RuntimeVisibleAnnotations和RuntimeInvisibleAnnotations属性。BCEL未来的版本应该会包含这种功能而不是作为插件提供。
编译时刻的字节码重构方法显示在示例代码的code/02_compiletime目录中。
但是这种方法有很多缺陷。首先，我必须给建立过程增加额外的步骤。我不能基于命令行设置或其它编译时没有提供的信息来决定打开或关闭重构操作。如果重构的或没有重构的代码需要同时在产品环境中运行，那么就必须建立两个单独的.jars文件，而且还必须决定使用哪一个。
|
|
|
|
|
|
|
|
|
