没有策略性枪击，没有争议性投票，在我们享受五一长假的过程中，JDO2.0规范的首轮议会投票结束了。
自从2004年4月20日JDO2.0规范的制定流程（JSR243）开动以来，JDO又开始回到人们的视线中，并且在五一假期结束之前，规范的制定委员会成员陆续地进行了投票，以表达各自的支持程度，目前投票已经全部结束。下面列举一下投票结果，并在最后发表几点个人愚见。
下面先列举一下投票结果：
2004年4月30日，Sun公司投票支持JDO2.0，并发表了以下声明：
本声明是作为对之前的一些投票声明的回应：
如果没有JDO，那我们很值得为Java是否应该在这一领域作出发展进行讨论，其利和弊都显而易见。不过既然JDO已经存在，并且已经有了足够的用户群，并且他们希望JDO继续发展下去。Sun作为JDO规范的领导者，理所当然地感受到进一步发展JDO的紧迫性。
Sun相信JDO与EJB可以共存，我希望两方面的专家组可以充分协调以避免不必要的规范重叠。而JDO是否应该归入J2EE将是以后的论题。
基于目前JDO已经存在并吸引了相当多的Java开发用户群的目光的情况下，我想眼下最重要的是让JDO在吸收用户反馈和新需求的基础上进一步发展。
- Graham
2004年4月20日，Lea, Doug（纽约州立大学计算系） 投票表示支持
2004年4月20日，SAP AG 公司投票表示支持
2004年4月20日，Monson-Haefel公司, Richard 投票表示支持
2004年4月22日，IONA Technologies PLC 公司投票表示支持
2004年4月26日，Nokia Networks 公司投票表示支持
2004年4月26日，BEA公司投票表示反对，并发表下述声明：
JDO目前属于众多的服务端数据持久性解决方案中的一种。在J2EE1.5已经将重点放在降低复杂性和增加易用性的情况下，我们不明白为什么还要继续推出新版JDO，它的市场集中在有限的对象数据库方面，此外，EJB3中也将会加入相似的一些（类似JDO的）改进。我们需要慎重考虑如何将JDO引入到其它一些新的领域，比如离散数据集支持等等，这样的结合会有什么后果。除非这些疑问得到阐释，否则我们相信Java社区更应该将精力集中到更有竞争力的同类技术上去。
2004年4月26日，Apache Software Foundation 投票表示支持
2004年4月30日，Fujitsu Limited 投票表示支持
2004年4月30日，IBM投票表示反对，并发表下述声明：
这份Java规范需求建议对JDO进行的扩展明显地与其它已经启动的JSR有重叠的地方。在Java社区已经开始推动J2EE简化的趋势下，我们并不希望建立重复的机制来完成同样的功能。
2004年4月30日，Macromedia, Inc. 投票表示支持，并发表下述声明：
尽管我们不希望看到的JDO与其它JSR的重叠确实存在，我们长期以来听到的用户的呼声却是他们愿意自己去做决定如果处理这些重叠，而不是被平台厂商强制限制。用户往往希望自己选择多种数据存储方案中的一种，而不在乎为这些重复的技术多花些时间和精力进行研究及选择。我们支持JDO并不是因为它是一种完美的构想，而是基于广大用户的长期开发实践中的真实感受。
2004年5月2日，Caldera Systems 投票表示支持
2004年5月3日，Hewlett-Packard 投票表示支持
2004年5月3日，Apple Computer, Inc. 投票表示支持
2004年5月3日，Oracle 投票表示反对，并发表下述声明：
JDO2.0与EJB3.0专家组正提出的轻量级存储模型有冲突。让两种以上的规范来描述同样的问题，而又使用不同的API、不同的存储和事务语义、不同的映射定义和查询机制，这样无法使J2EE变得更简单易用。EJB3.0的轻量级存储方案将完美地满足主流的企业Java应用开发者，包括那些现在对EntityBean模型提出批评的人。总之，既然EJB3.0已经在进展之中，另一个独立的数据存储标准是没有必要的，它只会使眼下正想采纳J2EE的决策者更加无所适从。
以上就是参与J2EE规范制定的16个武林帮派的投票结果（Borland弃权）。总的来说，是12票支持3票反对1票弃权，算是通过了。不过我们在反对的三票当中，可以琢磨出一些耐人寻味的东西：
Oracle在去年就对JDO一直怀恨在心，何解？Toplink也！因为JDO直接威胁了非标准的Toplink的市场，甚至有相当多的呼声要求Toplink出新版支持JDO的API，这样当然影响到Toplink已经锁住的众多企业用户。
IBM和BEA？多数中小规模的数据库应用并不需要象EJB这样复杂的体系，而JDO和其它一些轻量级的O/R映射技术正好填补这一空白，也许这一点决定了IBM和BEA的态度。两者是当前EJB市场的绝对两个大腕，安内必先攘外，在对EJB3.0进行积极支持并计划以最快速度占领市场的同时，碰到JDO这个可能会在企业数据库开发市场分一杯羹的新技术，二者当然会暂时摒弃前嫌，合力对付这样的异己。从这一方面来看，两个公司相互支持的胸怀值得景仰，完全不象抗日日期的国民党。话说回来，二者的态度最终还是为自己的利益服务的，这也是一个商业公司的基本原则，不过象BEA所指的JDO仅限于对象数据库范围的应用，就纯属无稽之谈了。
作为规范领导者，Sun的态度不言而喻。而JDO与JSP2.0可以更好地结合，使得页面制作人员可以简单地在HTML编辑器中完成动态数据的结合，Macromedia自然是双手赞成。
令人迷惑的是，一向主张在软件开发中以人为本的Borland此时为何保持缄默？难道它最近的动向是.NET？这里笔者也不便妄作揣测，只保持关注即可，一切的答案留给时间来公布。
下面我们来看看争论焦点的EJB3.0有些什么样的东西。
利用J2SE1.5提供的标注功能简化EJB描述符。J2SE1.5确实太伟大了，可以对类、方法、字段等等进行嵌入式的注解，这样，我们可以指望将来省掉所有的描述符、元数据之类的东西。尽管原来我们已经有XDoclet来帮助开发，但它对存储映射细节的描述毕竟只存在于源代码中，现在J2SE1.5的注解可以存在于编译好的类二进制代码中，真快哉！不过这一点完全不能证明JDO与EJB3.0发生了冲突，这只是另外一个范畴的改变，就象Intel又出了更高频率的CPU，JDO和EJB都可以享受一样，不能说明JDO与EJB发生冲突
提供更多的默认行为，这样可以有效减少配置工作量。这一点目前而言JDO已经比EntityBean做得好得多得多。
提供预定义的适配器类，减少开发人员需要实现的接口数目。在JDO中默认情况下你无需要实现任何接口，因此无法再减少。这方面可能不如EJB了？
更方便的JNDI处理。这是EJB本身的顽疾，这里不再评论。
无状态会话Bean的简化。这与JDO无关
对CMP实体Bean以及相关的EJBQL进行更好的支持。这是关键所在，也是与JDO所谓的冲突最集中的地方。EJBQL和JDOQL也许是两种不同的查询规范，但一定要将二者合而为一，还是将选择权留给用户？EJBQL只能静态配置，如何动态化还未有指望，这方面可以说目前无法与JDO进行冲突吧。
减少一些必须捕捉的异常。一些与业务逻辑无关的异常将转化为动态异常。这方面，目前JDO的涉及数据库操作的所有异常都已经被包装为动态异常，只有必要的情况下才需要捕捉。这也是EJB向JDO靠拢的一点体现。
性能调节的功能。这也与本文无关
其它一些专家组提出的改进。
综上所述，我们看到JDO出现以来，Java数据库开发方面有了可喜的变化，大家不必局限于复杂的EJB，或者一些无法替代的现有O/R映射技术，而是有了新的，规范化的选择。这些结果都影响着整个业界，包括EJB。希望Oracle、IBM、BEA这几个Java界的巨头能够从用户出发，从实际出发，认真面对这一改变。
最后需要说明的是，笔者本人是JDO的支持者，但希望听到不同的声音。欢迎大家对此发表评论。（在http://theserverside.com/news/thread.tss?thread_id=25695上已经有很多网友进行评论了）
本译文的版权属于笔者本人，但欢迎转载，前提是注明出处和原作者。另外，欢迎在我的专栏中查看我的另几篇文章，并提出宝贵意见！
