更正对AspectJ的一些误解

一直都在关注AOP的发展动向，也接触和试用了好几个AOP的不同实现。出于偶然的原因，最近两个礼拜真正有机会了解了一下AspectJ，让我赞叹AspectJ的强大。可是由此却让我开始反思另外一件事情。最早知道AspectJ至少有一年时间了。按照常理来说，作为最完整实现AOP概念，拥有“鼻祖”和“AOP实现参考”的AspectJ，理应更受我的关注。可是我却一直对它敬而远之，为什么？由于AspectJ 5以前的实现更偏重于静态织入，导致需要使用特定的ajc而不是javac来编译源代码。再者使用Aspectj需要另外学习一套语法，对初学者并不友好，当然也有自己懒惰的因素。然而更为重要的原因是道听途说的认为AspectJ对源代码直接进行静态织入，导致最后编译的是修改后的源代码，进而导致出错时Java异常报告的行数等相关信息将与源代码完全无法吻合。这使我认为AspectJ将无法在生产环境下使用，只能作为学术研究成果的结论。有一段时间我甚至认为类似AspectJ这样的代码生成和静态织入技术将完全被基于动态代理的AOP实现取代。就这样草率的宣布了AspectJ的“死刑”。

事实情况如何呢？当我正倾注大量的热心于AspectWerkz的时候，忽然得知AspectJ和AspectWerkz合并的消息。由于AspectWerkz是通过运行期动态织入字节码的方式实现AOP，能够正确的报告异常，我就疑惑结合后的AspectJ 5如何解决这个问题。经过一番小小的折腾后，搭建起了AspectJ的环境，经过测试，让我大为吃惊的是：AspectJ一样能够非常正确的报告出错行数等相关信息，丝毫没有引起调试的任何困难！参考附件的截图。

可以清楚的看到，经过AspectJ编译后的代码，运行时正确的抛出了异常，并正确的报告了错误行号，堆栈等错误信息。没有出现我预想的情景。

整个过程给我的教训是：不要轻易将道听途说的东西作为技术判断的依据。

有意思的是恰好在几个礼拜前，看到gigix在程序员杂志上发表的“动态代理的前世今生”一文中针对AspectJ提出的两点缺陷：1. 需要预编译，影响开发节奏；2. 静态织入导致调试困难。gigix或许是犯了和我一样的错误：过于信任道听途说的东西。对于1，仅仅是用ajc替换javac，换了一个编译工具而已，就像我们习惯用ant或maven一样，并没有明显的预编译过程。在安装了插件的eclipse环境中更是无缝集成，开发人员感觉不到和平常编译有任何不同。而对于2,　事实已经证明丝毫不会干扰运行和调试。

Eclipse有专门针对AspectJ的工具项目：AJDT。已经比较成熟和稳定。在这个工具的帮助下，可以对AspectJ的语法高亮，语法检查，代码自动完成，甚至可以直接观察到哪些类的哪些方法被Aspect切入了，又或是某个Aspect都切入了哪些类。甚至直接在这些关系间导航...大大降低了开发的难度，这些都是其它AOP实现所无法比拟的。

AspectJ 5将是AspectJ和AspectWerkz结合后正式发布的第一个版本，同时拥有原来AspectJ的强大的静态以及AspectWerkz灵活的动态织入能力，你甚至不用学习原来AspectJ特有的语法，使用纯粹的Java开发AOP应用，再加上AJDT良好的支持，将进一步确立它在AOP方面的王者地位和事实标准。

AspectJ http://www.eclipse.org/aspectj
AJDT http://www.eclipse.org/ajdt
AJDT 新功能的介绍　http://www.eclipse.org/ajdt/whatsnew120M2

哦，程序员上的《动态代理的前世今生》是gigix写的啊？呵呵，写得很好，值得一读，不过也说明自己孤陋寡闻，对不上名，呵呵。
   看来，javaeye上做AOP的，有蛮多牛人嘛，楼主，多贴些这样的经验，与大家共享。

多谢指正。我的那些观点倒不是道听途说，是来自实践经验。不过我用AspectJ的时候它甚至还没搬到Eclipse.org，显然版本太老还不完善，我是把一个旧观念一直保持至今了。幸亏你的指正来得及时，我还来得及把J2EE without EJB里面的一个注脚修正过来。

什么时候能看到啊，等得好着急

我非常期待今年三月份AspectJ 5的正式发布，和AspectWerkz结合后的AspectJ将同时拥有静态织入的高效强大和动态织入的灵活。再回头参照一下现在流行的基于DynamicProxy实现的AOP已经没有任何优势可以和AspectJ相比。