在Java世界Hibernate是最引人关注的一个话题从Gavin King加入EJB EG负责制订EJB的持久层规范到Gavin King非正式退出JDO EG并且充满个人情绪的攻击JDO规范到《Hibernate in Action》的发行再到Hibernate Alpha的发布最后再到最近JBoss PR的发布（使用Hibernate实现Entity Bean）可以说这其中的每一步都引起业界的侧目
Hibernate在不到年的时间里从一个不起眼的开源软件发展到今天令业界瞩目的主流O/R Mapping框架Gavin King从一个开源软件的作者成为业界举足轻重的人物这多少有些传奇的色彩毕竟单纯从技术成就而言Hibernate不算是最有成就的Java开源框架软件到目前为止也不是一个完美无缺的软件从个人技术水平而言Gavin King也不算绝顶高手
在当前的Java持久层框架中最流行的O/R Mapping产品分别是HibernateJDO和TopLink
自从去年Gavin King加入JBoss之后Hibernate已经由一个民间的开源软件走上了兼容EJB EntityBean的道路然而更加令人侧目的是Gavin King在EJB EG中充当了一个非常重要的角色只要对比一下EJB的EntityBean和Hibernate真相就会大白虽然API接口不同但是 EntityBean的设计理念完全来自于Hibernate
虽然EJB的EntityBean在相当程度上来源于Hibernate但是毕竟是不同的API接口因此Hibernate和EJB EntityBean究竟是怎样的一种关系是很多人心中的疑问
年四月份JBoss的Ben Wang访华期间我曾经向Ben请教Hibernate的未来发展他回答说Hibernate未来将仍旧以独立的软件产品存在和发展既可以 outside EJB container使用同时Hibernate也将做为JBoss EntityBean Implementation又可以inside EJB container使用然而如何既inside又outside终究缺乏一个感性的认识
月日JBoss发布的 EJB PR揭开了答案从Sourceforge的CVS服务器上面checkout出来源代码看一下我们可以发现Gavin King对Hibernate进行了简单的封装将EJB EntityBean API调用转换为内部Hibernate自己的API从而实现EJB EntityBean的兼容
EJB 不承诺脱离容器调用如果你想享用EJB则必须运行在某个EJB Vendor提供的容器内例如你使用JBoss提供的容器那么你调用的是EntityBean API这些调用请求会被转换为Hibernate API的调用请求这意味着Hibernate实际上提供了两套API一套是Hibernate原生API另一套是兼容EJB EntityBean API对于那些需要分布式调用支持需要EJB容器的开发人员来说他们选择后一套API对于不需要EJB容器的开发人员来说他们选择前一套 API这就是Hibernate既定的发展策略
今年夏天投票通过的JDO标准从某种程度而言并不逊色于 Hibernate当前的版本有些功能甚至比Hibernate还要好例如 JDO支持对类属性的lazy loading而Hibernate要到才支持当前Hibernate仅仅支持类的lazy loading实际上在去年就已经有很多用户不断提出对类属性的lazy loading的需求然而Gavin King当时一直不认为这个需求有添加的必要性再例如被Gavin King形容为可憎的JDOQL实际上是类SQL查询语言和对象条件查询的混合体从功能上来说不如HQL强大但是比Hibernate自己的条件查询强
不知道究竟出于什么原因Gavin King对JDO似乎一直怀有由衷的厌恶月他在Hibernate的blog上面对JDO进行了毫不留情的批判列举了JDO的种种缺点来解释为什么EJB持久层规范没有把JDO考虑进去然而事实上他的批判充满了对JDO的误解和偏见例如Gavin King憎恨JDOQL丝毫没有什么特别的理由只因为JDOQL不是一个纯粹的查询语言而是一个混合体这多少让人对Gavin King的风度感到遗憾在被Solarmetric的Abe White反驳之后同样没有风度的说我可没有时间做这种无谓的争论事实上每个人都认为他自己的技术是最好的……我是错了JDO那伙人也错了每个人都会犯错误……（所以说人无完人！）
JDO规范的出台事实上构成了对Hibernate乃至基于 Hibernate理念的EJB EntityBean的严重威胁JDO规范在功能上的严重缺失导致了JDO无力面对Hibernate和TopLink的竞争然而功能基本完备的JDO挟众多JDO Vendor商业支持的合力同时JDO规范可以避免产品锁定在某个Vendor的优势已经将竞争的天平拉直
然而JDO和EJB两大商业主流标准的分裂是大部分人甚至包括厂商所不希望看到的 于是最终EJB的Lead Linda DeMichiel和JDO的Lead Craig Russell联名发表公开信宣布了一个合并EJB和JDO持久层规范的计划新的持久层规范将以JSR（EJB）的持久层规范为基础融合JDO的部分特性新的持久层规范将进入JEE之中独立于EJB存在既可以inside JEE容器来使用也可以脱离JEE容器独立的运行
这个新的持久层框架可以说完全是一个政治的产物EJB Vendors出于自身利益反对JDO使得JDO没有办法成为JEE的一部分然而标准的分裂也是大部分人更加不希望看到的于是最终JDO成了政治斗争的牺牲品从表面上来看JDO和EJB EntityBean都将被新的持久层框架取代似乎JDO并没有吃亏但实际上JDO标准已经成熟部分JDO领导厂商的产品已经蓄始待发而 EJB EntityBean还处于Early Draft等待产品诞生至少也是一年之后的事情了另外值得耐人寻味的是新的持久层框架将基于当前EJB EntityBean再结合JDO的规范并且将处于EJB EG的控制之下再加入一些JDO EG的成员因此可以看出来新的持久层框架无疑还是以EJB EG为主导进行制定的
从长远来看EJB和JDO 的政治斗争对双方都有好处长期分裂带来的后果对双方的发展都不利然而从短期来看JDO确实是在这场政治斗争中败下阵来最直接的体现就是已经有一些JDO的用户对JDO的前景产生了动摇和迷茫不少的JDO爱好者更是直言JDO将死
TopLink是一个老牌的 O/R Mapping软件了自从被Oracle收购之后又增加了对Oracle数据库的良好支持和对Oracle AS EntityBean的支持Oracle提供了TopLink的图形设计环境可以使得设计好的TopLink域模型既可以被单独用在TopLink 中也可以被用在EJB CMP中因此看来TopLink也走了一条和Hibernate同样策略的路
TopLink的问题在于相比Hibernate的开源和免费的优势来说TopLink既不开源售价又不菲上本来商业软件TopLink应该在技术支持和商业宣传策略上拥有足够的优势然而Oracle公司毕竟是一个以数据库为核心产品的公司其他的一切产品都是为了数据库销售业绩而服务的在Oracle产品线中处于一个从属地位的TopLink由于先天不足只能眼睁睁看着Hibernate的日益壮大而无所作为因此 TopLink更多的被局限在购买了Oracle数据库并且绑定Oracle数据库的用户群体中
JEE的新持久层规范将毫无悬念的成为未来持久层框架的主流API无论是HibernateJDO还是TopLink终将兼容这个主流商业API在当前的这三种持久层API当中Hibernate无疑是最有前途的这是因为新的持久层规范将基于EJB EntityBean规范这意味着仍将以Hibernate的设计理念为基础
JBoss对EJB规范跟随的步伐非常紧密在规范制定过程中就不断的发布参考实现产品因此可以对对EJB规范产生比较大的影响力
综上所述我们有理由对Hibernate的前途抱有强烈的信心
最后的一个疑问是既然JEE的新持久层框架可以脱离JEE容器运行那么大家不全部都去用Hibernate的后一套兼容API而完全放弃Hibernate的原生API了吗？那么是否意味着Hibernate做为一个独立产品的使命彻底终结呢？
对于这个问题我的看法是JEE的持久层规范要综合各个EJB VendorJDO Vendor的意见要平衡他们之间的利益得失那么这样一个瞻前顾后的规范必然无法覆盖所有应用场合的全面需要这不像Hibernate的原生API 可以随时根据开发人员的要求增加功能那么灵活因此我预计Hibernate的原生API以其更加强大的功能仍然会吸引一大批人直接使用原生API而不是兼容JEE规范的API
总而言之对于我们当前的持久层开发来说最好的办法莫过于坚定的使用DAO层来隔离持久层和业务层逻辑那么不管未来持久层风云如何变换但凡基于POJO的持久层框架都可以被我们拿来任意替换
