现在的位置: 首页 > 综合 > 正文

风云变幻之JDO2.0

2013年09月20日 ⁄ 综合 ⁄ 共 5305字 ⁄ 字号小中大 ⁄ 评论关闭

风云变幻之JDO2.0

JDO2.0一波三折，尤其这一次，遭受重创。JDO2.0立项以后，道路就不平坦，平静中潜伏杀机，我早已觉得有写一点东西的必要了。

从9月份的被迫的EJB合并，到现在的大打出手，可谓惨不忍睹。而投票结果更是多年来JCP中最具"政治"意味的投票，因为没有任何一个反对票是基于技术理由。

经过几天的心情沉重之后，我终于可以静下心来反思一下了，为什么会这样，以后会怎样，现在可以做什么。。。

我正觉得有写一点东西的必要了。

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厂商群雄并起，储侯争霸，出现百花齐放的局面。不达，尽管很多厂商扩展功能实际上是一回事，但各家厂商有各家的特点和具体实现方式，特别是实现O/R Mapping映射都属于厂商的扩展功能，让开发者难以抉择。在这样的局面下，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厂商代表，他们的市场显然会受到影响。这一次，我真是体会到了“月有阴晴圆缺”的道理！