风云变幻之JDO2.0
JDO2.0一波三折，尤其这一次，遭受重创。JDO2.0立项以后，道路就不平坦，平静中潜伏杀机，我早已觉得有写一点东西的必要了。
从9月份的被迫的EJB合并，到现在的大打出手，可谓惨不忍睹。经过几天的心情沉重之后，我终于可以静下心来反思一下了，为什么会这样，以后会怎样，现在可以做什么。。。
我正觉得有写一点东西的必要了。
1 背景
JDO，Java Data Objects，一个小巧玲珑的轻量级对象存储标准，从一出生就充满了坎坷。单立项到第一版规范公布，就花了三年时间，现世之初，功能还比较局限，目标定位也比较窄，就是提供轻量级的对象包装，不依赖任何特殊的中间件或J2EE容器，只要有JDK就够了，做简单的应用时，开发过程变得非常简单，开发者不必再关心底层数据库的实现细节，只需要以面向对象的观念去组织、构建自己的数据对象模型，再操纵这个模型即可。在当今流行的“简单就是美”的概念下，JDO这一点得到了很多人的认同，尤其是在纷乱的对象／关系映射领域，终于有一个统一一点的轻量级标准，实在是不容易。当然，此时的JDO还属于概念级，很多人只是在观望，同时提供有限的支持和推广，象IBM，早期就有一些宣传JDO的文章。随着时间的推移，JDO厂商也越来越多，所属的国家也越来越多（比较令人自豪的是Charles Huang领导的中国人自己的JDO产品：Liberator），慢慢呈现出国际化的趋势，由于JDO厂商之间相互竞争，JDO产品的质量逐步提高，以厂商扩展（Vendor-Extension）方式提供的功能也越来越实用，JDO开始获得开发人员的认同和实施，尤其是以前使用过EJB实体Bean的人（包括我本人在内），在经历EJB的繁琐的配置、发布、调试过程和高要求的服务器环境维护以后，慢慢地将目光投向JDO，经过一些初始尝试之后，大家尝到了甜头，加上JDO厂商众多，免费到高端产品一应俱全，不太会成为几家厂商霸占市场的局面，JDO开始进入实用阶段。
JDO开发到底简单在哪里？快在哪里？以我领导开发的两个项目作例子可说明一切：
太平洋电脑网二手市场：http://es.pconline.com.cn/ 这是花了5个人天做出来的，包括设计和代码开发，中途还多次修改或取消已完成的功能，数据库结构也多次更改。在测试阶段出现的BUG多是一些易用性方面的东西，比以前使用JDBC方式引起的数据不一致或关联问题的错误少很多，时间上比以前使用JDBC方式至少节省了1个月时间，或者说60%的时间。
太平洋网站群评论系统：http://cmt.pconline.com.cn/ 这是最近投入使用的一套让网友对太平洋各网站文章进行自由评论的系统，虽然简单，但数据量是很大的，在已有的几百万条评论的基础上，现在平均每日发表的评论六七千篇，并且还在逐日上升，里面完全是面向对象的设计，在实际性能和速度上比直接的JDBC要好得多。这一点足以说明JDO的伸缩性，应对大数量的数据库开发也是游刃有余。当然，高性能的底层数据库也是必要的基础。
好了，书归正传，刚才谈到JDO开始获得普遍认同，各JDO厂商群雄并起，储侯争霸，出现百花齐放的局面。各家厂商有各家的特点，尽管很多厂商扩展功能实际上是一回事，但API方面各不相同，让开发者难以抉择。在这样的局面下，JDO2.0规范也箭在弦上，目标是将开发者常用的那些扩展功能都统一规范，让开发者做出的JDO应用能在各个厂商产品之间最大程度地兼容，从而可以灵活选择更合适的产品（考虑因素主要包括地域性、技术支持等），在2003年的JavaOne大会和8月的JDO2.0规范启动会议上，大家制定了2.0规范的目标，开始紧锣密鼓地制定新的API和语义标准。
在这段JDO快速发展的同时，Java世界本身也有了很多变化。J2SE1.4和J2EE1.4的先后发布，令开发者的应用开发更容易，JSP2.0的使用，让Web开发容错性更好，代码更简单。尤其要提的是，EJB3.0规范也开始进入制定过程，各大EJB厂商下决心痛改前非，将EJB不断瘦身成一个苗条灵活的组件体系，让开发人员不再为复杂的配置和接口头疼，甚至让EJB不再依赖于J2EE服务器，而是直接提供POJO（简单的Java对象）支持。不过，EJB3.0是直接定位在JDK5.0的基础上的，它的量产也依赖于JDK5的广泛接受，而JDK5从业界的规律来看，估计要到2006年以后，才会成为主流。
JDO2.0经过专家组（包括我在内）一年多的努力，终于出台了全新的规范，但好景不长，业界风云变幻，如今形势危急，尤其是在中国的传统佳节—中秋节之后，涟漪变为波澜，真可谓是往事不堪回首月明中！
2 分析
这一节我们一起来仔细地琢磨琢磨此次风波的过程，Java世界的人间百态。
先说大气候，EJB的复杂、O/R Mapping的混乱催生了JDO，而JDO又以简单、轻量级的特点备受中小软件开发企业的亲睐。而大企业呢？一般决定软件技术路线的人也是慢慢由中小企业吸收而来，这样来看，JDO也会逐渐进入大型软件开发，其灵活多样的配置选择能让比较复杂的大型应用也完全运行在完全免费的体系架构上面，这种灵活性在业界中已经有Linux、Apache、Ant等优秀的产品印证过。这个时候，对EJB绝对是一种考验，一则尽量简化，让开发者知道EJB也可以非常简单，二则突出JDO的弱点，比如生命期还年轻，技术支持不完善等等，三则直接将JDO吸收进EJB。结果这几方面在实际变幻过程中，都得到了体现。
再说小气候，这将涉及多个厂商或团体态度的逐渐变化
JDO的出现对开源团体是一大鼓舞，在JDO1.0出台之初，JBoss是非常支持的，它还组织专门的团队立项开发了JBossDO，作为一个开源的JDO产品，因为当时JBoss作为J2EE平台提供商，还未得到Sun的正式承认，在J2EE容器方面，JBoss已经做得不错，而如果要提供企业级应用开发，一个数据库底层是必要的，JBoss此时选择了JDO，正是因为JDO简单，对开发者有吸引力，符合JBoss一贯的特点。不过在后期JBoss态度开始暧昧，先是JBoss终于得到Sun的正式承认（通过了J2EE TCK检验），然后是JBoss高层开始向商业化方向发展，并收购了同样是有一定用户基础的开源O/R映射产品Hibernate，而Hibernate的负责人Gavlin King开始倾向于将Hibernate融合进EJB，成为其POJO支持的底层，这时，JBoss自然需要向EJB倾斜，因此，作为JDO2.0专家组的一员，JBoss在规范制定的后期开始逐渐淡出，直至如今投了反对票。
有些类似的是，Apache集团对JDO的态度也经历了一些变化，只不过与JBoss正相反。最初，Apache旗下的Jakarta开发组有自己的几套数据库底层，象Turbine中的Torque，象OJB（Object Java Bridge）等等，都是有一定有历史的。JDO初期，Apache也只是观望，并未给予很大支持，OJB中增加了一点对JDO API的接口，不过在相当长地时间内这方面都没有什么发展。不过作为JDO2.0专家组的一员，Apache后期的贡献非常大，它利用自己的开源优势和实力，主动承担JDO2.0示范产品（Reference Implementation）的工作，目标是为广大开发者提供一个强劲、易用、免费的JDO底层，让自己在业界的声誉和地位吸引更多的观望者加入JDO阵营。这也是我比较崇敬的地方。
现在该Hibernate出场了，它原来也是一个独立的O/R产品，免费和不断改进是它最大的特点，可以说，它是原先纷乱的O/R市场中最引人注目的，尤其是在开源社区，它也因此获得2003年最佳Java产品之一的称号。很多对EJB不满的开发者都尝试并使用了它，成为它广大用户群的一员。最初Hibernate估计也是想成为JDO的领导者，不过Hibernate特有的语法和完全针对关系数据库的特点，不适合JDO的统一规范和面向不只是关系数据库的远大目标，因此，Hibernate仍然是走着自己的路。Galvin King对业界的贡献和他本身的恒心和毅力确实也是令人折服。不过JDO逐渐成熟起来之后，Hibernate是受到冲击最大的，很多网上的争论都是为了在JDO和Hibernate之间得到一个明确的选择。而这一时刻，EJB3.0正好想学习JDO的不依赖J2EE容器的灵活性，需要一个POJO支持的底层，Hibernate似乎是被相中了，之后Hibernate又被JBoss收购，开始唯JBoss马首是瞻，并且JBoss在JDO2.0规范制定专家组中的代表就换成了Galvin King，那就是后话了。
Oracle一向对JDO不怀好感，它曾收购了Toplink，即在原来的O/R Mapping市场中性能似乎是最好的，但价钱也是最高、API也是最特别的一个产品。Oracle希望通过Toplink弥补EJB的不足，在非EJB的数据库开发市场也赢得先机，达到全面盈收的目的。所以Oracle一直都是不支持JDO的，尽管如此，Oracle在去年的Toplink新版中，加入了很多类似JDO的元素，换句话说，就是将JDO的一些特点融合进Toplink中。
IBM最初对JDO还是挺支持的，IBM的一些技术专家还写过文章介绍JDO。不过这两年，IBM逐渐取代BEA成为J2EE市场的老大，大型企业的数据库开发选择BEA的EJB的也不在少数，因此不难理解IBM后期对JDO的强大表现出的担忧。
HP就比较墙头草了，在本次JDO2.0规范的最终投票上，在去年5月的JDO2.0早期规范（JCP制定Java规范的一个比较前面的必须过程）的投票中，HP坚定不移地投了赞成票，在前几天的JDO2.0公众评审版（JCP制定Java规范的一个比较后期的必须过程）的投票中，HP好象是一开始赞成，但在看了其它几个巨头的投票和评论后，也改投了反对票，真是让人一声叹息！
日本富士通倒是冷眼旁观，只简单地说了一句希望解释清楚与EJB的关系，就投了反对票。在这里，我要感叹一下，好象也没看到富士通对Java业界有多大贡献，但却是JCP执行委员会的一员，很是令人纳闷。如果是换成中国的联想或方正，或许投票会公正些。
Borland公司一向是代表开发人员的，尽管它自己也是EJB厂商，但百花齐放，鼓励竞争一向是Borland的原则，就象它同时推出Java和.NET的IDE一样。
好了，我也不多说了，通过上面的一些简单分析，我们可以看得出来，此次令人遗憾的JDO2.0投票结果，是Java业界大气候与O/R Mapping界小气候共同决定的，是不以人的意志为转移的。不过，在风云变幻的过程中，我个人觉得还是有些地方做得不好，比如在JDO1.0出台后，David Jordan写了篇文章《CMP or JDO？》，描述CMP和JDO的区别及如何选择。或许那篇文章容易误导读者，将JDO与EJB对立起来，进而引起不必要的纠纷。
3 过程与前景
JDO2.0规范从2003年8月制定愿景开始，经过一番争论地决定，在2004年4月正式开始了JCP的标准规范制定过程，即JSR243。4月底对需不需要开展JDO2.0规范的投票中，IBM、Oracle、BEA三巨头的反对，就为JDO2.0埋下了隐忧。不过规范制定专家组没有理会这些，而是专心工作，逐步将前期讨论的结果整理出来，在6月下旬公布了前期草案（Early Draft）。之后，不断讨论如何让开发者更方便地使用JDO，如何增加更多实用的功能到标准之中，完全没有理会外界的风起云涌。
作为JDO的用户之一，我能看到的比较大的很实用的改变就有：对完整的Map及Collection框架的正式支持，JDOQL增强（自动识别参数和变量等等），关系数据库的更完美支持（统计功能、保持数据结构不变的厂商间移植），数据存取细节的控制、二级缓冲的细粒度控制的API等等，都是非常有利于应用系统的扩展的。
直到9月份中秋佳节，我还请了几天假去九寨沟耍了一把，玩得真是痛快，但回来上网才发现，大事不好，EJB要吞并JDO，合并后的规范还是叫EJB3.0，并且领导者不再是JDO的头Craig Russell，而是EJB的头Linda（巾帼不让须眉！）。那几天专家组里人人都很是忿忿不平，尤其是大部分成员都是JDO厂商代表，他们的市场显然会受到影响。这一次，我真是体会到了“月有阴晴圆缺”的道理！
大家紧急商量对策，不过，Craig Russell此时显然受到了来自各方的压力，包括他的上司，Sun的高层管理者。最终，一封公开信向公众展示了JDO的屈服：“JDO2.0将只是JDO1.01的细微改进版，以完善旧版为主要目的”。本来，我们的目的是先软化矛盾，缓和冲突，再将已经制定的JDO2.0规范中的功能完善化，取越王勾践之气节，卧薪尝胆，厚积薄发，以图一出世而主宰市场。不过这一招看来是失败了，因为我们只想到了用户会接受并推崇JDO2.0，而没有仔细想过最终投票的却主要是当今雄霸天下的EJB巨头们。JDO2.0在9月份时已经是完全超越了1.0的功能范围，加入了太多的实用功能，已经完全不是简单的JDO1.0完善版了。正是公开信中的这句话，成为今天备受攻击的目标。
之后，JDO2.0专家组中的6位成员被挑选到EJB3.0专家组中，参与EJB3.0的规范制定，而Craig则顶住各方压力，继续完善JDO2.0。
中国有句古话：是福不是祸，是祸躲不过。现在矛盾已经激化，并且在目前的形势下，JDO只有继续屈服。
不过，中肯地说，JDO与EJB3.0都是面向简单的POJO支持，如何选择，很多用户至今无所适从。这次投票正好将这个问题直接提上台面，无论谁是谁非，对用户而言，标准不统一最终会造成困扰。从现在的规范内容看，JDO2.0提供的功能确实要多过EJB3.0的范围，并且现有的厂商支持已经足以让用户马上开始进行JDO2.0的开发。而EJB3.0的规范定稿到最终的厂商产品大量出现，没有1年的时间是不太现实的。换个角度，从用户的角度看，EJB历史悠久，至少知道EJB这个名词的人比知道JDO的要多，也许EJB3.0更易被企业用户接受。最好的办法是以EJB3.0的名义推出JDO2.0，不过这当然是痴人说梦，一厢情愿。此事古难全，还需另寻良方。
现在双方的意见大概是EJB3.0会提供一套全新的API，EntityManager之类，这套API将支持J2EE环境和非J2EE环境，更直接地说，JDO2.0将会通过这套API得到支持，现有的JDO厂商的产品可以经过不太复杂的改造来支持EJB3.0的POJO。从这一点上看，很可能EJB3.0的非容器版会更早上市。
而对JDO本身来说，此次投票并不意味着JDO的消亡，专家组下一步的工作是向EJB3.0看齐，将API、映射方式等细节与EJB3.0统一起来，也许会有一些Proxy API来桥接JDO的API和EJB3.0的API，这样，以后用JDO2.0开发出的东西可以方便地移植到EJB3.0的其它产品中去。
夜正长，路也正长，我们还会继续走下去。。。
4 行动
我们现在可以为JDO做点什么呢？
其实答案并不复杂，让更多人认同JDO，让JCP执行委员会知道JDO的重要，就是我们的当务之急。至少我们可以做到以下几点：
1． 在各网站和论坛发表文章，表达自己的观点，尤其是熟悉英文的读者可以去theServerSide.com，onjava.com，oreilly.com等知名业界媒体网站上去发表自己的意见
2． 说服投反对票的那些公司的人员。当然，这不是一蹴而就的事情，我们周围如果有朋友在IBM、Oracle、HP、富士通等公司任职并涉及Java开发，可以向他们介绍JDO的作用和重要性，他们可以向公司内的投票代表发邮件转达意见
3． 最重要的，是开发者的意见，如果是已经在JDO上有投入并有一定积累的用户，可以直接向JCP执行委员会发邮件质询，描述自己的情况，争取保护自己的投资
4． JDO厂商，可以总结自己的客户的情况，向JCP表明立场
据我所知，一些国外的使用了JDO的企业，就发出了质询的邮件，希望JCP尊重自己的投入，不要因为一些无意义的策略方面的调整导致JDO的终结。其中有一封邮件还直接发给了JDO规范组，痛骂规范组成员为什么投票反对JDO，当然，他这是搞错对象了，把受害者当成了凶手。不过多多少少让大家得到一丝慰藉：JDO后面还有很多用户的支持！
5 参考
说了这么多，并不能带来多少转机，更多的努力，要靠大家共同付出。
最后，给出一些链接，给各位读者参考：
1． JDO2.0规范主页，上面有两次投票的详细情况链接，还有最新版规范的下载
http://jcp.org/en/jsr/detail?id=243
2． JDO主要讨论区
http://jdocentral.com/forums/index.php
3． JDO2.0中对JDOQL的改进介绍
http://www.csdn.net/develop/Read_Article.asp?Id=26400
4． JDO规范领导者Craig Russell的介绍
http://www.oreillynet.com/cs/catalog/view/au/1118?x-t=book.view&CMP=IL7015
