目击凶案——JDO 2.0投票结果点评

（本文将发表于《程序员》2005年第2期）

就像电影里的老套路，我今天要说：“我有一个好消息，也有一个坏消息。”

好消息是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，他们都乐于帮助开发者降低系统开发的难度，他们都乐于成为开发者的朋友……

只要应用系统继续使用他们的高端服务器！<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

这才是问题的关键所在。任何的友谊、任何的开发者关系，都必须建立在这条底线之上。任何一个做过J2EE应用开发的程序员都知道，IBM WebSphere、BEA WebLogic、Oracle Application Server等带有EJB容器的J2EE应用服务器都售价不斐，而且运行这些应用服务器对硬件环境的要求也更高——国内有很多电子政务项目都是在“IBM小型机+AIX+WebSphere”的“贵族环境”下运行。同样，任何一个做过J2EE应用开发的程序员都知道，大多数中小型web应用其实根本不需要这么高档的环境，太多的软硬件资源其实是被白白浪费了。但是，只要继续使用EJB，你就必须同时选择一个昂贵的、带有EJB容器的应用服务器，以及一台能让庞大的应用服务器正常运行的高端服务器——哪怕你的网站每天只有10万访问量，你也别无选择。

Java技术社群在努力改变这种现状。时下流行的、基于IoC和AOP的轻量级架构，以及JDO和Hibernate等基于POJO的持久化框架都致力于帮助J2EE应用摆脱对EJB容器的依赖。实践证明，采用这些轻量级的架构，再加上合理的设计和配置，国内至少90%的电子政务和电子商务系统完全可以在servlet容器上运行，根本不需要用到EJB。这对于开发者是件好事，因为他们只需要在一台普通的PC上装上Tomcat，就可以得到一个开发环境，开发出的产品同样可以适应绝大多数用户的需求。而且，摆脱了EJB烦琐的部署和调试，开发效率将大大提高，又不必购买昂贵的服务器软硬件，企业的成本也将有效降低。

但大厂商们又会怎么想呢？“90%的项目不再使用EJB”，从高端应用服务器赚取巨额利润的BEA、IBM、Oracle……怎么可能眼睁睁看着这种事情发生？于是JDO 2.0就成了那只被枪打的出头鸟：提供便利而强大的O/R mapping，很好，所有厂商都愿意帮开发者这个忙，但是必须在EJB的体系之内；像JDO 2.0这样在EJB体系之外提供J2SE/J2EE皆可使用的O/R mapping，岂不是给了广大开发者又一个抛弃EJB的理由？大厂商们自然必先除之而后快了。

这是笔者一厢情愿的猜测吗？让我们来看看那些反对票背后的意见吧：

Ø IBM：JDO 2.0与其他Java持久化技术存在明显的竞争，目前的规范草案未能澄清如何解决这些竞争。

Ø BEA：JSR-243（即JDO 2.0）会给Java持久化产品市场带来混乱。

Ø JBoss：JDO 2.0应该作为JDO 1.0.1的维护版本存在，尽量少引入更多的新特性。

Ø Oracle：我们感觉JSR-243与其他Java持久化技术有所重复，这会造成持久化技术领域的混乱，并且降低整个J2EE社群的生产率。

Ø 富士通：JDO 2.0应该划清与其他Java持久化技术之间的界限。

看到这里，故事的答案已经昭然若揭了——那个反复被提起的“其他Java持久化技术”，不是EJB 3.0 entity bean又是什么？如果说持久化技术的市场目前呈现“entity bean-JDO-Hibernate”鼎足三分的格局，现在Hibernate的创始人已经加入了EJB阵营，只要再把JDO限制在现有版本的小修小补，不让它有长足发展，那么entity bean自然就成为了Java世界唯一强势的持久化技术。剩下的问题也就只是几家应用服务器厂商之间如何瓜分市场份额了，总之肥水不流外人田。算盘果然打得好精！

老话说得好，没有永远的朋友，只有永远的利益。虽然BEA和IBM在应用服务器市场上拼得你死我活，虽然JBoss一直以“程序员的代言人”自居，一旦触及到利益底线，大厂商们立即站到了同一边——站到了开发者和中小软件企业的对立面。不过幸好，开发者也有自己的利益同盟：Apache已经上马了开源的JDO 2.0实现项目，Kodo、Lido等商业产品也会继续为中小企业提供价廉物美的JDO支持。唯一可惜的是，恐怕我们无法看到JDO 2.0的技术规范正式发布了——至少是在EJB 3.0正式发布之前。

最后，读者也许要问：大厂商们说“JDO 2.0会给持久化技术市场带来混乱”，这也并非无理取闹。Java开发者们不是常常为选择太多而烦恼吗？这个问题，就留给读者自己去思考吧。下面列出两张赞成票附带的意见，或许会对读者有所启发。

Ø Apache：也许JDO 2的确会与EJB 3.0 entity bean形成竞争，但抉择不应该由几家厂商来做出。应该允许百花齐放，由市场决定成败。

Ø Borland：只有引入充分的竞争，才能让整个Java社群得到最好的技术。

---

[1] 详见《程序员》2004年第6期《剖析EJB》一文。