前言：
提到AOP，便不得不提到两个产品，一个是Bea赞助的开源项目AspectWerkz，另一个就是IBM的AspectJ，其后，两个团队合并，其创始人投奔Terracotta，BEA被甲骨文收购，而Sun被Oracle收购是众所皆知。
我们现在摘录的这篇文章便涉及BEA大名鼎鼎的工具JRockit。JRockit JVM Support For AOP，英文版可以到Oracle网站上搜索。
文章摘录：
面向方面编程（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单元。方面由联结点、切点、建议和引入来定义（也称为类型间声明）。
以下略，如感兴趣可看原文，这里是另外一个版本。
扩展阅读