就像电影里的老套路，我今天要说：“我有一个好消息，也有一个坏消息。”
好消息是AspectJ和AspectWerkz合并了。这两家都是业界重要的开源AOP实现，不过走了不同的技术路线：AspectJ一直坚持“预编译+源码生成”，AspectWerkz则是“元数据+运行时织入”的代表。关于两种技术路线、两种产品的争论一直是AOP社群的热点话题，如今两个开源组织决定彻底解决这个困扰。两家合并之后的第一个产品将是AspectJ 5，其中既有AspectJ风格的、基于语言扩展的AOP，也有AspectWerkz风格的、基于XML(和JSR-175 annotation)的AOP。随后，双方还会继续融合各自的长处和经验，努力提供一个完善而统一的AOP平台。
这是一件好事——对于开发者而言。写过AOP程序的人都知道，AspectJ和AspectWerkz(当然，还有其他AOP框架)之间的选择是很伤神的：前者有很多的资源可以利用，但偏偏用了一套无法移植的自定语法；后者使用标准的Java语法和XML配置，移植性没问题，却又没多少资源可以利用。虽然AspectJ 5还不可能一劳永逸地解决这些问题，但至少让我们看到了希望：AOP社群的领袖们在努力消除障碍，努力让程序员们有一个更好的开发平台。AspectWerkz已经在第一时间把自己的网站首页改成和AspectJ一样的风格，从这件小事你可以感受到：为了整个开发者社群的利益，这些技术高手们根本不介意各自的门户派别。不像有些人……
这个“有些人”是在指谁？别着急，现在该说说那个坏消息了。坏消息来自JCP，JSR-243(JDO 2.0)规范的公开评审(public review)投票结果让我大吃一惊：16张选票有10张反对。我也跟踪过好些个JSR的投票，比如JSR-168(Portlet)、JSR-94(Java规则引擎)、JSR-54(JDBC 3.0)等等，似乎从没见过哪个JSR遭遇如此之多的反对票。JSR-243专家组里也有两位中国人Sun Bin(孙滨)和Charles Huang(黄海波)，打个电话给他们，他们都会告诉你：这是一个相当成熟的技术规范，而且已经有不少商业化的实现产品。既然如此，又是谁在反对JDO 2.0成为真正的技术规范呢？看看下面这张图就一清二楚了：
一眼看去，红叉前面的公司名字要么是在高端J2EE应用服务器市场上风光无限(譬如BEA和Oracle)，要么是在高端服务器硬件市场上独领风骚(譬如IBM和HP)；而绿勾前面的名字却能让开发者们觉得亲切：Apache、Borland、Sun，还有并发程序设计的“教父”Doug Lea。直觉告诉我，这里似乎是“开发者利益 vs. 厂商利益”的一个战场了。不过，要看懂这场战争的来龙去脉，故事还得从EJB说起。
回到EJB 2.x的时代，很多架构师恐怕都还记得这样一个最佳实践：“使用无状态session bean，不使用entity bean”。作为EJB体系的持久化技术方案，entity bean是一个彻头彻尾的败笔[1]。Java开发者们需要O/R mapping，但entity bean无法胜任。在相当长的一段时间里，JDO和Hibernate是Java社群最热门的O/R mapping技术。JDO也是JSR技术规范之一(JSR-12)，但作为O/R mapping还有一些细节上的缺陷；Hibernate是一个民间性质的开源项目，尽管没有什么名分，但从实用出发的设计思路让它受到最多的欢迎。
持久化是一个如此普遍的问题，持久化工具背后蕴涵着一个如此庞大的市场，大厂商们不可能对其视而不见。于是，在EJB 3.0规范(JSR-220)的预览草案中，我们看到了一个与Hibernate极度类似的entity bean设计方案，Hibernate的作者Gavin King也顺理成章地成为了EJB 3.0专家组的成员。EJB 3.0规范的简介这样写道：“EJB 3.0将彻底改进EJB架构，从开发者的角度降低其复杂度。”这样看来，不管IBM还是BEA还是HP，他们都乐于帮助开发者降低系统开发的难度，他们都乐于成为开发者的朋友……
