面向方面编程（aspect-oriented programming，aop）正在软件社区和企业界中获得强大的发展动力。自从20世纪90年代xerox引入了aop之后，aop经过研究团体、开源社区和企业界的数次推动和革新，已经越来越成熟了。在java领域，近两年开源运动已经获得了极大的推动，这导致aspectwerkz和aspectj最近合并在一起，现在它们都归入eclipse foundation，代号为aspectj 5。aspectj是由bea systems公司和ibm公司发起的，可以认为它是使用java实现aop的事实标准。

　　随着aop流行程度的逐渐增加和研究团体的不懈努力，词汇表、概念和实现已经趋于一致，这得到了更完善的工具支持，允许更好的开发者体验，比如，出现了aspectj eclipse插件aspectj development tools (ajdt)。

　　aop已经经历了多种实现技术，从源代码操作到字节码测试（这是java中一种广泛采用的技术，特别是在java 5 jvmti出现之后）。如今，在应用程序管理和监视领域，有多种应用aop的企业级产品采用了这种技术，并且最近随着基于pojo（plain old java object）的中间件和透明集群的出现而变得越来越流行。

　　因此，无论如何，字节码测试越来越可能成为你最终必须掌握的东西。你将不得不回答下面这些问题：字节码测试技术究竟能够把可管理性、透明性和效率扩展和实现到什么程度？依赖于字节码测试的aop实现会不会发展到尽头，以至无法为更高的效率、易用性和动态性做进一步的革新？jvm对aop的支持会解决这些问题吗？能够解决到什么程度？本系列文章通过揭示bea jrockit jvm aop支持的内幕以及激发在这个领域中的争论，来提供这些问题的具体答案。

　　第一篇文章介绍aop概念并且简单地说明为什么许多实现（比如aspectj）要基于字节码操作。它解释了与字节码测试技术相关的一些限制，以及它们为什么会在长期运行过程中影响可伸缩性和可用性。然后，最后一节介绍jrockit jvm对aop的支持，这一技术的目标是克服这些限制，为aop和其他截取机制提供一个高效率的后端。

　　本系列文章的第2部分将通过具体的api细节和示例来说明这种支持的力度。

什么是面向方面编程?

　　面向对象的分析和设计引入了继承、抽象和多态等概念，由此为我们提供了降低软件复杂性的工具。但是，开发人员在软件设计过程中仍然经常会面对无法用面向对象软件开发技术轻易解决的问题。这些问题之一就是如何处理应用程序中的横切关注点（cross-cutting concerns）。

横切关注点

　　关注点就是设计人员感兴趣的某一概念或区域。例如，在一个订货系统中，核心关注点可能是订单处理和生产，而系统关注点可能是事务处理和安全管理。

　　横切关注点是影响多个类或模块的关注点，即未能很好地局部化和模块化的关注点。

　　横切关注点的表现有：

　　?代码纠结――当一个模块或代码段同时管理多个关注点时发生这种情况。

　　?代码分散――当一个关注点分布在许多模块中并且未能很好地局部化和模块化时发生这种情况。

　　这些现象会从几个方面影响软件；例如，它们会导致软件难以维护和重用，并且难以编写和理解。

关注点的隔离

　　面向方面编程试图通过引入“关注点的隔离”这一概念来解决这些问题。采用这一概念，可以以一种模块化而且适当局部化的方式实现关注点。aop解决这个问题的办法是在设计空间中增加额外一维，并且引入了一些构造，这些构造使我们能够定义横切关注点，将它们转移进新的维，并且以模块化方式将它们打包。

aop引入的新构造

　　aop引入了一些新的构造。联结点（join point）构造准确反映了程序流中定义良好的点，例如调用方法的地方或者捕获异常的地方。切点（pointcut）构造使我们能够挑选出匹配某一标准的联结点。建议（advice）构造使我们能够添加应该在匹配的联结点执行的代码。引入（introduction）构造使我们能够向现有的类添加额外的代码，例如，向现有的类添加方法、字段或接口。最后，aop引入了方面（aspect）构造，这是模块化的aop单元。方面由联结点、切点、建议和引入来定义（也称为类型间声明）。

用aspectj实现aop的示例

　　下面是一些简单的aspectj 5代码示例，它们在一定程度上说明了如何在代码中实现上面定义的概念。要想进一步了解特定的aop语言细节，请参考aspectj文档。

// using a dedicated syntax// that compliments the java languagepublic aspect foo {  pointcut somelistoperation() : call(* list+.add(..));  pointcut userscope() : within(com.biz..*);  before() : somelistoperation() && userscope() {    system.out.println("called: "        + thisjoinpoint.getsignature()    );  }}

　　以上代码使用了一种专门的语法。可以使用java注释写出等效的代码。

// the java 5 annotations approach@aspectpublic class foo {  @pointcut("call(* java.util.list+.add(..))")  public void somelistoperation() {}  @pointcut("within(com.biz..*)")  public void userscope() {}  @before("somelistoperation() && userscope()")  public void before(joinpoint thisjoinpoint) {    system.out.println("called: "        + thisjoinpoint.getsignature()    );  }}

　　以上代码定义了一个方面foo，它具有两个切点somelistoperation()和userscope()。这些切点将在应用程序中挑选出一组联结点。它们组合在一起成为一个布尔表达式somelistoperation() && userscope()，这样在扩展list的任何类型实例上，在每次调用名为add的任何方法之前都会执行before建议，前提条件是：调用是从com.biz包（及其子包）中的某些代码发出的。这样，before建议会在所有这些联结点上输出将被调用的方法的签名。第二个代码示例定义了一个非常相似的方面，只是采用了一种依赖java 5注释的替代语法。

什么是编织?

　　正如前一节和代码示例所描述的，方面可以对整个应用程序进行横切。编织（waving）就是将方面和常规的面向对象应用程序“织”成一个单元（单个应用程序）的过程。

　　编织可以在不同时期进行：

• 编译时编织：例如，在部署之前（因此也在运行时之前）进行代码的后期处理（aspectj 1.x中采用）。
• 装载时编织：在装载类的时候（也就是在部署时）进行编织（aspectwerkz 2.0中采用）。
• 运行时编织：编织可以在应用程序生命周期中的任何时候进行（jrockit 和steamloom中采用）。

　　这个过程还能以多种不同方式进行：

• 源代码编织：输入是已开发的源代码，而输出是经过修改的调用方面的源代码（aspectj 1.x中采用）。
• 字节码编织：输入是编译出来的应用程序类的字节码，而输出是经过调整的编织过的应用程序的字节码（aspectwerkz 2.0和aspectj 1.1以及更高版本中采用）。

　　源代码编织受到一定的限制，所有源代码必须可用并提供给编织器，这样才能应用方面。这就导致某些目标不可能实现，例如实现通用的监视服务。编译时编织也受到同一问题的困扰：在编译后进行部署之前，需要把将部署的所有字节码准备好。

　　本系列文章全面介绍了字节码编织和jvm 编织，从下一节开始将讨论这些内容。

　　随便提一下动态代理（dynamic proxies），这是一种受限的编织方式，它在jvm中已经存在了一段时间了。这个api自从1.3版开始就是jdk的一部分，它允许为一个接口（和/或一系列接口）创建一个动态虚拟代理，这样就有可能截取对这个代理的每个调用，并且将其重定向到你希望的任何地方。根据定义，这并不是真正的编织，但是它与编织类似的地方是它提供了进行方法截取的简单方式。各种框架采用它来进行简单的aop，例如spring framework。

基于字节码测试进行编织的问题

测试是低效率的

　　编织的实际测试部分往往非常消耗cpu，而且有时还会消耗大量内存。这会影响启动时间。例如，要想截取所有对tostring()方法的调用或者对某个字段的所有访问，需要逐一分析所有类中的几乎每一条字节码指令。这还意味着字节码测试框架将创建许多中间表示结构，以一种有用的方式公开字节码指令。这可能意味着编织器需要分析整个应用程序（包括第三方库等）中所有类中的所有字节码指令。在糟糕的情况下，这可能会涵盖超过10, 000个类。

　　如果使用多个编织器，那么开销就会成倍增加。

双重记录：为编织器构建类数据库是代价高昂的

　　为了知道类、方法或字段是否应该被编织，编织器需要对这个类或成员的元数据进行匹配。大多数aop框架和应用aop的产品具有某种高级表达式语言（切点表达式），用于定义代码块（建议）应该被编织在哪里（在哪些联结点上）。例如，这些表达式语言使你能够挑选出具有某种返回类型的所有方法，这种类型实现了类型t的接口。在代表对特定方法m进行调用的字节码指令中，这一信息是不可用的。了解这个特定方法m是否应该被编织的唯一办法是，在某种形式的类数据库中查找它，查询它的返回类型，并且检查它的返回类型是否实现了给定的接口t。

　　你可能会认为：为什么不只使用java.lang.reflect.* api？在这里使用反射的问题是，如果不触发这个类的类装载，就无法通过反射查询java类型，这将在我们掌握进行编织所需的足够信息（在装载时编织基础架构中）之前触发这个类的编织。简单地说，这就成了典型的鸡生蛋/蛋生鸡问题。

　　因此，编织器需要一个类数据库（常常从硬盘读取原始字节码，在内存中建立），这样才能对实际的联结点是否需要某个方法进行必要的查询。有时候，可以通过限制表达式语言的可表达性来避免这个问题，但是这种做法常常会限制产品的可用性。

　　一旦编织完成，这个内存中的类数据库就是多余的。jvm已经在它自己的数据库中保存了所有信息，而且是经过优化的（比如，它为java.lang.reflect api服务就使用这些信息）。所以，我们最终对整个类结构（对象模型）进行了双重记录，这会不必要地消耗可观的内存，而且由于创建这个类数据库以及在发生变化时维护它，会增加启动开销。

　　如果使用多个编织器，那么开销就会成倍增加。

hotswap：在运行时改变字节码会增加复杂性

　　java 5引入了hotswap api，作为jvmti规范的一部分。在java 5之前，这个api只有运行于调试模式时才可用，而且只对本机c/c++ jvm扩展有效。这个api允许在运行时修改字节码――即重新定义一个类。一些aop框架和应用aop的产品使用它模拟运行时编织功能。

　　尽管这个api非常强大，但是它在以下这些方面限制了可用性和可伸缩性：

• 它的效率不高。因为在运行时改变字节码，所以在运行时也会产生测试开销（cpu开销和内存开销）。另外，如果需要修改许多地方，就意味着要重新定义许多类。然后，jvm将不得不重新执行它以前可能执行过的所有优化和内联工作。
• 它受到很大的限制。这个api没有指定当前运行字节码的地方可以安全更改。因此，编织器需要假设此字节码在硬盘上，否则它就需要跟踪此字节码。当使用多个编织器时，这是个大问题，这在下一节解释。

　　另外，hotswap api的当前实现不支持方案修改（schema change），规范中将此功能声明为可选的。这意味着不可能在运行时修改类的方案，例如，添加底层测试模型可能需要的方法/字段/接口。这导致不可能实现某些运行时编织类型，并且因此要求用户提前“准备好”类。

多个代理是个问题

　　当多个产品正在使用字节码测试时，可能会发生出乎意料的问题。问题涉及到先后次序、更改通知、更改撤消等。这在当今可能还不是个大问题，但是以后将成为严重的问题。编织器可以视为代理（jvmti规范中就是采用这种称呼），它在装载时或运行时执行测试。当使用多个代理时，就会存在很高的风险，因为代理以各自的方式获得字节码，并可能以出乎下一个代理意料的方式修改字节码，而原来假设是只有单独配置的代理。

　　下面是当两个代理互不了解时出现问题的例子。如果有人使用两个代理――一个编织器和某个应用程序性能产品，它们都在装载时执行字节码测试，根据配置，编织后的代码可能是也可能不是性能度量的一部分，如下所示：

// say this is the original user codevoid businessmethod() {  usercode.do();}//---- case 1// say the aop weaver was applied before the// performance management weaver// the woven code will behave like:void businessmethod() {  try {    performanceenter();    aopbeforeexecuting();//hypothetical advice    usercode.do()  } finally {    performanceexit();  }}// ie the aop code affect the measure//---- case 2// say the aop weaver was applied after the// performance management weaver// the woven code will behave like:void businessmethod() {  aopbeforeexecuting();//hypothetical advice  try {    performanceenter();    usercode.do()  } finally {    performanceexit();  }}// ie the aop code will not affect the measure

　　关于这些代理的先后次序有一个问题；在联结点（或切点）级别上没有控制次序的细粒度配置方法。

　　某些其他情况可能导致更加无法预测的结果。例如，当一个字段访问被截取时，这往往意味着字段获取（field get）字节码指令被移动到一个新添加的方法，并且被替换为对这个新方法的调用。因此，下一个编织器将在代码中的另一个位置（在那个新添加的方法中）看到一个字段访问，而它自己的匹配机制和配置可能不匹配这个位置。

　　总之，主要问题如下：

• 代理看到哪些字节码？问题是，正常情况下，被编织的字节码是从类装载管道获得的，但是建立类数据库所依赖的字节码是从硬盘读取的。当涉及多个代理时，硬盘上的字节码不再是正在执行的字节码了；因为某个代理可能已经修改了字节码，这意味着第二个代理看到的是错误的字节码视图。当使用hotswap api时，也会发生这种情况。
• 当代理a撤消或者改变它的编织操作时，可能会出现问题。如果另一个代理b在代理a之后已经执行了修改，那么代理b可能已经重新构造了字节码，导致字节码看起来完全不一样了（尽管其功能是一样的），在此情况下，代理a就不知道该怎么做了。

截取反射式调用是不可能的

　　当前的编织方式只能测试（至少是部分地）可静态确定的执行流。请考虑以下代码示例，它在给定的实例foo上调用方法void doa()。

public void invokea(object foo) throws throwable {  method ma = foo.getclass().getdeclaredmethod("doa",
 new class[0]);  ma.invoke(foo, new object[0]);}

　　在现代的代码库中常常使用这种反射式访问来创建实例、调用方法或者访问字段。

　　从字节码的角度来看，对方法void doa()的调用是看不到的。编织器只看到对java.lang.reflect api的调用。还没有简单且高效的办法可以对通过反射执行的调用进行编织。目前，这对于如何执行编织以及如何实现aop是很重要的限制。最好的办法是，开发人员使用执行端切点来代替。显然，从jvm的角度来看，存在一个对doa()方法的方法调度，尽管这在源代码或字节码中没有出现。已经证明，jvm编织是以高效的方式解决这个问题的唯一编织机制。

其他问题

　　某些人对字节码测试持怀疑态度，尤其是在动态执行的情况下（在装载时或运行时）。对于动态修改代码，存在着一种不应低估的情绪化影响，尤其是在与某种盲目的革命性新技术（比如aop或服务的透明式插入）结合使用时。在涉及多个代理时可能发生的混乱将增加人们的怀疑。

　　另一个潜在的问题是java规范中对类文件规定的64kb边界。方法体的字节码指令总长度被限制为64kb。在编织已经很大的类文件（例如，将jsp文件编译为servlet时产生的类文件）时，这可能会导致问题。在处理这个类时，可能会突破64kb的限制，这就会导致运行时错误。

提议的解决方案

　　对于上面讨论的大多数问题，jvm编织是自然的解决方案。为了理解其原因，我们将查看两个示例。这些示例说明，jvm已经做了执行编织所需的大多数工作：当类被装载时，jvm读取字节码以便建立为java.lang.reflect.* api服务所需的数据。另一个例子是方法调度。现代的jvm将方法或代码块的字节码编译为更高级而且更高效的构造和执行流（在可以应用代码内联的地方进行代码内联）。由于hotswap api的需要，jrockit jvm（可能还包括其他jvm）还会记录哪个方法调用了其他方法，这样如果在运行时重新定义某个类，那么在所有期望的位置（内联的或非内联的），类中定义的方法体仍然可以被热交换。

　　因此，不必为了编织进一个建议调用而修改字节码，比如说在特定的方法调用之前。jvm实际上可以掌握关于这个建议调用的知识，它会在任何匹配的联结点上对此建议进行调度，然后再调度实际的方法。

　　由于不接触字节码，可以预期到直接的好处，比如：

• 不会由于字节码测试而导致启动开销。
• 对于在任何位置、任何时间、以线性开销添加和删除建议的完全的运行时支持。
• 对建议的反射式调用的隐式支持。
• 不需要占用额外的内存来将类模型复制到某些框架特有的结构。

　　本系列的第二篇文章将详细描述提议的jrockit jvm对aop的支持。

　　以下代码示例作了总结性说明。它在调用sayhello()方法之前对静态方法advice()进行调度：

public class hello {  // -- the sample method to intercept  public void sayhello() {    system.out.println("hello world");  }  // -- using the jrockit jvm support for aop  static void weave() throws throwable {    // match on method name    stringfilter methodname = new stringfilter(        "sayhello",        stringfilter.type.exact    );    // match on callee type    classfilter klass = new classfilter(        hello.class,        false,        null    );    // advice is a regular method dispatch    method advice = aspect.class.getdeclaredmethod(        "advice",        new class[0]    );    // get a jrockit weaver and subscribe the    // advice to the join point picked out by the filter    weaver w = weaverfactory.createweaver();    w.addsubscription(new methodsubscription(        new methodfilter(            0,            null,            klass,            methodname,            null,            null        ),        methodsubscription.insertiontype.before,        advice    ));  }  // -- sample code  static void test() {    new hello().sayhello();  }  public static void main(string a[])  throws throwable {    weave();    test();  }  // -- the sample aspect  public static class aspect {    public static void advice() {        system.out.println("about to say:");    }  }}

结束语

　　在java社区中已经开始流行使用字节码测试来实现中间件领域中的高级技术，比如aop或者透明式服务插入。但是，几个关键的限制妨碍了字节码测试，而且它的广泛使用将导致更多的问题，影响可伸缩性和可用性。

　　因为字节码测试在某种程度上已经成了在aop中实现编织的标准方式，所以本文中描述的限制和问题将会妨碍它（可能已经妨碍它了）。

　　我们相信，jvm对aop的支持是这些问题的自然解决方案。我们将要提供一个已经在jrockit jvm中实现的基于订阅的api，它与jvm方法调度组件紧密集成。本系列中的下一篇文章将更详细地讲解这个api，并且解释如何解决每个问题。

其他资料

• jrockit technology center ?c 第一个具有aop支持的企业级jvm站点
• aspectwerkz ?c 普通java aop框架
• aspectj ?c 用java 实现aop的事实标准
• aosd ?c 面向方面的软件开发
• quick start guide to enterprise aop with aspectwerkz 2.0 - david teare写的一篇文章 (dev2dev，2005年4月)

　　前一篇文章介绍了面向方面编程和关注点分离的概念，解释了这种概念如何在方面构造的帮助下增强软件的模块化，以及如何使用它来补充面向对象编程。方面代表模块化的单元，并且由切点（何处）、建议（什么）以及类型间声明（在这个新的方面补充对象模型）组成。有许多技术可以将关注点编织进应用程序，在当今的java领域中，最常用的技术是字节码测试，在aspectwerkz和aspectj（从1.1版开始）中实现了这种技术。

　　但是，这种aop实现方式具有几个缺点，本系列的第1篇文章对此进行了详细解释。尽管在字节码测试领域还有很大的发展余地（包括java 5中的jvmti/jsr-163测试代理规范和高效字节码操作库，比如objectweb asm），但字节码测试代价不菲。此外，已经证明，使用字节码测试实现aop是不完善的。例如，如果不采用非常特殊且效率低下的解决方案，就无法通过切点匹配反射式方法调用或get和set字段。总的来说，所有基于字节码测试的产品都受到字节码测试技术相关问题的影响，而且随着这种技术的普及，问题将逐渐增加。

　　所有这些缺点促使jrockit团队提出了jvm对aop的支持。其目标是尽可能全面地实现当前的aop语义，同时不把jvm限制在某个特定的面向方面框架的语言细节和编程模型上。

　　本文通过具体的代码示例介绍该api，然后描述其好处及未来的发展方向。

我们的动机

　　让我们快速地回顾引入jvm的aop支持的技术动机。

　　jvm编织是对上面提到的问题最自然的解决方案。为了说明其原因，我们将引入两个例子，它们说明jvm已经完成了编织所涉及的大多数工作：当加载一个类时，jvm读取字节码，建立为java.lang.reflect.* api进行服务所需的数据；另一个例子是方法调度。目前的jvm将方法或代码块的字节码编译为更高级、效率也更高的构造和执行流（在适用代码内联的地方进行代码内联）。由于hotswap api的需要，jrockit jvm（可能还包括其他jvm）还会记录哪个方法调用了其他方法，因此如果在运行时重新定义某个类，那么在所有期望的位置（内联的或非内联的），类中定义的方法主体仍然可以进行热交换。

　　因此，不必为了编织进一个建议调用而修改字节码，比如说，在特定的方法调用之前。jvm实际上可以掌握关于这个建议调用的知识，它会在任何匹配的联结点上对此建议进行调度，然后再调度实际的方法。

　　由于不接触字节码，立即可以获得以下好处：

• 不会由于字节码测试而产生启动开销。
• 对于在任何位置、任何时间、以递增式开销添加和删除建议的完全的运行时支持。
• 对建议的反射式调用的隐式支持。
• 不需要将类模型复制到特定于框架的某些结构，因此减少了额外的内存占用。

　　与jvmdi_event_method_entry或jvmdi_event_field_access等jvmdi规范中定义的众所周知的c级别事件相比，这种方式有很大区别。在jvmdi中，必须首先处理c级别api，这使得它对于大多数开发人员来说有些复杂，而且难以分发。其次，规范没有提供细粒度的联结点匹配机制，而是要求预定所有这样的事件。这仍然会导致显著的开销，因此不得不进行调试。

我们的方法

　　我们想让您先了解一下如何在jvm中添加aop支持。关键之处在于我们在java api级别上提供了动作调度和预定（下面会详细描述）。因此，您可以写出下面这样的代码：

weaver w = weaverfactory.getweaver();
method staticactionmethod =simpleaction.class.getdeclaredmethod
("simplestaticaction",new class[0]//no arguments);
methodsubscription ms = new methodsubscription
(/* where to match*/,insertiontype.before,staticactionmethod);
w.addsubscription(ms);

　　如您所见，我们提供了一个可访问的jvm api，可以用它来实现更传统的aop方法。这为解决前面提到的传统aop实现问题提供了极大的灵活性，而且也使其他使用方式成为可能。下面几节将详细介绍这个api。

动作调度和预定

　　jrockit jvm aop支持公开了一个java api，它与jvm方法调度和对象模型组件紧密集成在一起。为了确保不使jvm被限制在当前或未来的任何特定于aop的技术方向上，我们决定实现一个动作调度和预定模型。

　　这个api使您能够在指定的切点上描述定义良好的预定，这样就能够注册jvm将要调度的动作。动作由以下组件组成：

• 一个常规java方法――我们称之为动作方法，对于每个匹配这个预定的联结点，都将调用这个方法。
• 一个可选的动作实例，在这个实例上调用动作方法。
• 一组可选的参数级注释，它们向jvm指出动作方法期望从调用堆栈获得哪些参数。

　　动作还可以分为before动作、after returning动作、after throwing动作或者instead-of动作（类似于aop的“around”概念）。

　　为了调用这个api，必须获得一个jrockit.ext.weaving.weaver实例的句柄。这个编织器实例根据它的调用者上下文来控制允许进行哪些操作。例如，在容器级编织器可以预定特定于应用程序的联结点时，用户可能不希望部署在应用服务器中的应用程序创建编织器，从而预定某些容器级或特定于jdk的联结点的动作方法。这种编织器可见性理念反映了底层类加载器的委托模型。

　　我们简单介绍一下这些构造如何映射到常规的aop构造，这有助于理解这个模型：

　　?预定可以视为一个有类型的联结点，或者就是一个有类型的联结点（字段get()、set()、方法call()等等），加上一个within()/withincode()切点。

　　?动作实例可以视为方面实例。

　　?动作方法可以视为建议。

　　熟悉aop的读者可能已经看出，要想用这个jvm级api实现一个完整的aop框架，还需要进行一些开发，包括一个（按照规定）管理方面实例化模型的中间层、cflow()切点的实现以及切点的完全合成和正交的实现。

api细节：动作方法

　　动作方法（与aop的建议概念相似）就像（作为方面的）常规类的常规java方法。它可以是static方法，也可以是成员方法。它的返回类型必须符合某些隐式约定，而且before动作的返回类型应该是void。对于instead-of动作（类似于aop的around建议语义），其返回类型还是作为动作调用结果的堆栈的类型。

　　动作方法可以有参数，参数的注释进一步控制上下文公开，如下面的代码示例所示：

import java.lang.reflect.*;
import jrockit.ext.weaving.*; 
public class simpleaction
{  public static void simplestaticaction()
{out.println("hello static action!");
}
 public void simpleaction() {out.println("hello action!");
}
 public void simpleaction(@calleemethod wmethod calleem,@callermethod wmethod callerm)
{out.println(callerm.getmethod().getname());
out.println(" calling ");
out.println(calleem.getmethod().getname());
} 
}

　　该代码示例引入了jrockit.ext.weaving.wmethod类。该类用作java.lang.reflect.method、java.lang.reflect.constructor和类的静态初始化器（它在java.lang.reflect.*中没有出现）的包装器。这与aspectj joinpoint.staticpart.getsignature()抽象化相似。

　　下面是当前定义的注释及其含义。

　　为了支持instead-of，并能够决定是否沿着截取链前进（就像在aop中通过joinpoint.proceed()概念实现），我们引入了jrockit.ext.weaving.invocationcontext构造，如下所示：

import jrockit.ext.weaving.*;public class insteadofaction {  public object instead(                  invocationcontext jp,                  @calleemethod method callee) {    return jp.proceed();  }}

api的细节：动作实例和动作类型

　　正如前面代码示例中所示，动作方法可以是静态的，也可以不是。如果动作方法不是静态的，那么就必须传递一个动作实例，jvm在这个实例上调用动作方法。

　　其语法风格与java开发人员使用java.lang.reflect.method.invoke(null/*static method*/, .../*args*/)对方法进行反射式调用一样。但是，利用jvm的aop支持，底层的动作调用根本不涉及任何反射。

　　允许用户控制动作实例，就会产生有趣的用例。例如，可以实现一个简单的委托模式，在运行时用另一个实现替换整个动作实例，而不涉及jvm的内部组件。

　　注意，这将有助于（按照规定）实现aop方面实例化模型，比如issingleton()、pertarget()、perthis()、percflow()等等，同时不会将jvm api限制在某些预定义的语义上。

　　在将预定注册到编织器实例之前，赋予它一个类型作为建议类型：before、instead-of、after-returning或after-throwing。

　　可以编写下面这样的代码来创建预定：

// get a weaver instance that will act as a// container for the subscription(s) we createweaver w = weaverfactory.getweaver();// regular java.lang.reflect is used to refer// to the action method "simplestaticaction()"method staticactionmethod =  simpleaction.class.getdeclaredmethod(      "simplestaticaction",      new class[0]//no arguments  );methodsubscription ms = new methodsubscription(    .../* where to match*/,    insertiontype.before,    staticactionmethod);w.addsubscription(ms);

　　该代码示例假设用户使用静态动作方法实现。也可以使用实例方法编写这个示例，在这种情况下，应该传递给methodsubscription一个包含类实例。

// use of an action instance to refer to the// non static action method "simpleaction()"method actionmethod =  simpleaction.class.getdeclaredmethod(      "simpleaction",      new class[0]// no arguments  );// instantiate the action instancesimpleaction actioninstance = new simpleaction();methodsubscription ms2 = new methodsubscription(    ...,// where to match, explained below    insertiontype.before,    actionmethod,    actioninstance);w.addsubscription(ms2);

　　诸如within()和withincode()类型模式之类的aop语义也通过该api的变体实现。

api细节：预定

　　如前面的代码示例所示，预定api依赖于java.lang.reflect.*对象模型和一些简单的抽象化（比如jrockit.ext.weaving.wmethod）来合并方法、构造函数和类的静态初始化器处理。

　　new methodsubscription(...)调用的第一个参数必须是jrockit.ext.weaving.filter实例，这个实例具有几个具体实现以便匹配方法、字段等等。

　　jrockit.ext.weaving.methodfilter实例用作定义，jvm编织器实现根据它进行联结点阴影匹配(shadow matching)。jrockit.ext.weaving.methodfilter允许根据以下各项进行过滤（还提供额外的结构支持within()/withincode()语义）：

• 方法修饰符（比如使用java.lang.reflect.modifier时的int）。
• class<? extends java.lang.annotation.annotation>，匹配方法运行时可见性注释。
• jrockit.ext.weaving.classfilter实例，匹配声明类型。
• jrockit.ext.weaving.stringfilter实例，匹配方法名。
• jrockit.ext.weaving.classfilter实例，匹配方法返回类型。
• jrockit.ext.weaving.userdefinedfilter实例，用于实现更精细的匹配逻辑。

　　使用jrockit.ext.weaving.userdefinedfilter回调机制来实现更高级的匹配方式（与spring aoporg.springframework.aop.methodmatcher和org.springframework.aop.classfilter相似）。

　　所有这些结构都是可选的，如果遇到null，就表示“任意匹配”。

　　jrockit.ext.weaving.classfilter提供一种类似的方式：

• class<? extends java.lang.annotation.annotation>，匹配类运行时可见性注释。
• class，匹配类类型。
• boolean值，表示是否匹配子类型。

　　因此，以下代码匹配所有名称以“bar”开头的方法调用。注意，在这个非常简单的例子中传递了好几个null值：

stringfilter sf =  new stringfilter("bar", startswith);methodfilter mf =  new methodfilter(0, null, null, sf, null, null);methodsubscription ms = new methodsubscription(    mf,    insertiontype.before,    staticactionmethod);w.addsubscription(ms);

　　作为更现实的例子，以下代码匹配所有三个ejb业务方法：

// prepare the pointcut to match// @stateless annotated classes business methodsmethodfilter ejbbizmethods = new methodfilter(    public_nonstatic,    // method annotation does not matter    null,    new classfilter(        // declaring class, the java.lang.class        // for the ejb we are currently manipulating        ejbclass,        // no subtypes matching        false,        // class annotation        stateless.class    ),    // ejb methods matching is handled    // in a userdefinedfilter below instead    null,    // return type does not matter    null,    // custom filter callback    new userdefinedfilter() {        public boolean match(                       methodfilter methodfilter,                       wmember member,                       wmethod within) {            return !isejblifecyclemethod(member);        }    });

好处

　　使用jvm编织而不是字节码测试有几个好处。从较高的层面来看，编织作为jvm功能的自然扩展出现，因此在许多方面它不那么具有侵入性，并且为性能、可伸缩性和可用性各方面带来了许多好处。

　　关于字节码编织的问题（尤其是在加载时编织的情况下）的详细讨论，请参考本系列的第1部分。以下好处解决了所有这些问题。

• 不使用字节码测试，增强了可伸缩性

　　字节码没有被修改。在jvm内部组件中，仍然采用从字节码到可执行代码的常规编译管道。使用字节码测试时，需要分析字节码指令并用某些中间结构来表示它们，这样才能在测试框架（aop编织器或基于字节码测试的产品）中操纵它们；而使用jvm编织不需要这么做。

　　编织器变得无所不在了。即使用户希望在启动时注册预定，这也不再是必须的。因为根本不需要分析字节码指令来寻找要截取的联结点，所以大大减少了应用程序的启动时间。这也提供了开发真正动态的系统的机会――动态意味着可以在任何时候部署方面和解除方面部署，而又不会由此引起额外的开销或复杂性。

• 不使用冗余的类型信息记录，降低了内存耗用并且提高了可伸缩性

　　因为不再进行字节码测试，因此与对象模型双重记录问题相关的问题就不会出现了。预定api依赖于java.lang.reflect.*模型，而这个模型已经以类似的方式向java开发人员提供了此信息。

• 多个代理可以保持一致

　　因为所编织的类的字节码没有经过修改，所以不会因为两个不同的代理以不兼容的方式修改字节码（相互隐藏原始程序的属性），而造成冲突。预定的注册次序起到了优先权规则的作用。注意，如果类是可序列化的，那么不会为了在运行时执行所编织的建议而向其添加隐藏结构，所以常规的序列化将得到充分支持。而字节码测试技术通常需要确定序列化能力是否有所保留（例如，serialversionuid字段的处理）。

• 支持截取反射式调用

　　通过使用jvm级方法调度，所有反射式调用（方法调用或者get或set字段）都可以被匹配，就像它们是常规调用，而且所有注册的动作都将被触发一样。这不需要任何额外的开销，也不涉及特定于实现的细节和复杂性。

未来的发展方向

　　尽管jvm编织很有帮助，而且解决了与字节码测试技术相关的可伸缩性和可用性问题，但是仍然必须解决一些缺陷才能使其完美地实现用例，这可能需要采用一些补充方法。

　　一些基于字节码测试的产品使用了细粒度更改，当前的jvm aop api还无法实现这一特性。某些用例处理同步块，因此不同的锁定机制（如：分布式锁定）可以透明地注入常规的应用程序。这样的细粒度动作常常要求对同步块进行有条件执行，甚至完全删除同步块，并使用某个专用锁定api调用来替换它。可以在jvm中解决这样的特定需求，但是实际上不可能找到一个对每种用例都有效的高效解决方案。还有必要提醒一下的是，目前领先的aop框架还不能将同步块公开为联结点。

　　在jvm级别上，无法轻松地实现aspectj定义的某些细粒度语义。例如，aspectj支持预初始化、初始化和构造函数执行切点。构造函数执行切点挑选出源代码中出现的构造函数，初始化切点挑选出获得已初始化实例的所有构造函数执行，包括this(...)构造函数委托。jvm难以把握这两者的差异。更具侵入性的代码内联策略可能会出现在哪些地方实际上也可能取决于编译器。

　　随着字节码测试逐渐流行起来，新的jvm api的引入肯定会遇到挑战。如果要开发一种同时适应两种jvm（支持新api的jvm，比如jrockit，以及不支持新api的jvm）的产品，那么成本会相当高。这个领域中的规范（如：jsr）可能有助于克服这种困难。

结束语

　　字节码测试技术目前已经在不同领域的java平台上得到广泛使用，从面向方面软件开发到更特定于应用的解决方案（如：应用程序监控、持久性或分布式计算）。随着字节码测试的可用性和透明性的提高，加载时编织和部署时测试将会流行起来。

　　遗憾的是，这种技术没有为可伸缩性和可用性需求提供适当的支持。特别是随着这种技术的应用越来越广泛，以及对来自不同产品的不同测试代理的混合使用，这个问题会越来越严重。jvm编织和jvm对aop的支持（比如在jrockit中所实现的）是解决这个问题的自然方法，可以促进革新和技术发展。jrockit团队所提出的java api将jvm方法调度内部组件与用户定义的动作联系起来，仅依赖于java.lang.reflect api的预定优雅地填补了以前的鸿沟，并解决了主要的可伸缩性和可用性问题。

　　这种新的api要想获得广泛采用，需要对它进行认真的评估，并将它应用于真实的用例，比如aop或者大型应用程序的运行时自适应。

参考资料

• jrockit jvm support for aop, part 1（jrockit jvm对aop的支持，第1部分），作者jonas bonér、joakim dahlstedt和alexandre vasseur（dev2dev，2005年8月）――即本系列的第1篇文章。
• jrockit technology center――第一个具有aop支持的企业级jvm的站点。
• 新闻组：jrockit.developer.interest.aop。
• aspectwerkz――普通java aop框架。
• aspectj――用java实现aop的事实标准。

　　quick start guide to enterprise aop with aspectwerkz 2.0，作者david teare（dev2dev，2005年4月）。