Answers:
一些注意事项：
海事组织，我建议休眠。
对于需要使用特定于Hibernate的功能时应采取的措施，已有一些意见/问题。有很多方法可以解决这个问题，但是我的建议是：
如果您不担心供应商合作的前景，那么请在Hibernate，其他JPA和JDO实现之间做出选择，包括您决策中的各种特定于供应商的扩展。
如果您对供应商捆绑的前景感到担心，并且不能不借助供应商特定的扩展而使用JPA，则不要使用JPA。（适用于JDO的Ditto）。
在现实中，你可能需要权衡多少你被厂商担心搭配与多少，你需要这些供应商特定的扩展。
还有其他一些因素，例如您/您的员工对相关技术的了解程度，产品在许可方面的成本，以及您相信谁的故事对于JDO和JPA将来会发生什么。
确保评估JDO的DataNucleus实现。我们从Hibernate开始，因为它似乎很受欢迎，但很快就意识到它不是100％透明的持久性解决方案。有太多的警告，文档中充斥着“如果您遇到这种情况，那么您必须编写这样的代码”，这剥夺了我们随意进行自由建模和编码的乐趣。JDO 从未使我调整代码或模型以使其“正常工作”。我可以像在“仅在内存中”使用它们一样来设计和编码简单的POJO，但是我可以透明地持久化它们。
与休眠相比，JDO / DataNucleus的另一个优点是它没有所有的运行时反射开销，并且由于使用了构建时间字节代码增强功能（对于大型项目，可能会增加1秒的构建时间）而具有更高的内存效率。而不是休眠的运行时反射驱动的代理模式。
使用Hibernate可能会让您感到烦恼的另一件事是，您必须引用您认为是对象的对象……它通常是对象的“代理”。如果没有字节码增强的好处，就需要代理模式来允许按需加载（即，避免在拉入顶层对象时拉入整个对象图）。准备重写equals和hashcode，因为您认为您引用的对象通常只是该对象的代理。
这是Hibernate遇到的挫折，而JDO却没有的例子：
http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53
如果您喜欢编码为“变通办法”，那么可以肯定，Hibernate适合您。如果您喜欢干净，纯净，面向对象，模型驱动的开发，那么您将所有时间都花在建模，设计和编码上，而又没有花在丑陋的解决方法上，那么花几个小时来评估JDO / DataNucleus。投资的小时数将返还一千倍。
在相当长的一段时间内，DataNucleus除了实现JDO持久性标准外，还实现了JPA持久性标准，因此将现有的JPA项目从Hibernate移植到DataNucleus应该非常简单，并且只需很少的代码更改即可获得DataNucleus的所有上述好处。 （如果有）。因此，就问题而言，在选择特定标准，JPA（仅适用于RDBMS）与JDO（RDBMS +无SQL + ODBMSes +其他）之间，DataNucleus支持这两种标准，Hibernate仅限于JPA。
选择ORM时要考虑的另一个问题是它的脏检查机制的效率-当它需要构造SQL以更新当前事务中已更改的对象时，这一点变得非常重要-尤其是当对象很多时。在此SO答案中有Hibernate脏检查机制的详细技术说明： 带有HIBERNATE的JPA插入速度非常慢
我最近评估并选择了一个Java项目的持久性框架，我的发现如下：
我看到的是，对JDO的支持主要是：
支持JPA的支持主要是：
我看到许多来自JPA开发人员的亲JPA帖子，他们显然没有使用过JDO / Datanucleus，因此为不使用JDO提供了较弱的论据。
我还看到很多JDO用户的帖子，这些用户已经迁移到JDO，因此更加快乐。
关于JPA越来越流行，这似乎部分是由于RDBMS供应商的支持，而不是技术上的优势。（听起来像VHS / Betamax）。
JDO及其参考实现Datanucleus显然还没有死，正如Google在GAE上采用它和在源代码（http://sourceforge.net/projects/datanucleus/）上进行积极开发所表明的那样。
由于字节码增强，我已经看到了许多有关JDO的抱怨，但是至今还没有关于它为什么不好的解释。
实际上，在一个越来越被NoSQL解决方案所困扰的世界中，JDO（和数据核实现）似乎是一个更安全的选择。
我刚刚开始使用JDO / Datanucleus并进行了设置，以便可以在db4o和mysql之间轻松切换。使用db4o有助于快速开发，而不必过多担心数据库模式，然后在稳定该模式以将其部署到数据库时就不必担心。我也有信心，以后，我可以将我的应用程序的全部/部分部署到GAE上，或者利用分布式存储/映射减少la base / hadoop / cassandra，而无需进行过多的重构。
我发现开始使用Datanucleus的最初障碍有些棘手-datanucleus网站上的文档有些难以理解-教程并没有我想要的那么容易。话虽如此，一旦您走过了最初的学习过程，有关API和映射的更详细的文档就非常有用。
答案是，这取决于您想要什么。我宁愿使用更简洁的代码，没有供应商锁定，更倾向于pojo取向，nosql选项和更受欢迎。
如果您希望自己与大多数其他开发人员/绵羊一样在做事，请选择JPA /休眠。如果您想领导该领域，请测试JDO / Datanucleus，并下定决心。
您对新项目有何建议？
我不建议！使用Spring DAO的JdbcTemplate一起StoredProcedure，RowMapper和RowCallbackHandler来代替。
我自己对Hibernate的亲身经历是，前期节省的时间已被无休止的日子所抵消，您将花费大量时间来尝试理解和调试问题，例如意外的级联更新行为。
如果您使用的是关系数据库，那么您的代码离它越近，您拥有的控制权就越大。Spring的DAO层允许对映射层进行精细控制，同时消除了对样板代码的需求。而且，它还集成到Spring的事务层中，这意味着您可以非常轻松地（通过AOP）添加复杂的事务行为，而不会干扰代码（当然，您也可以通过Hibernate获得它）。
JDO死了
JDO实际上还没有死，所以请检查您的事实。JDO 2.2已于2008年10月发布。JDO2.3正在开发中。
这是在Apache下公开开发的。比JPA发行的版本更多，其ORM规范甚至比JPA2提议的功能还先进
我正在使用JPA（来自Apache的OpenJPA实现，该实现基于KODO JDO代码库已有5年以上的历史了，并且非常快速/可靠）。恕我直言，任何告诉您绕过规格的人都给您不好的建议。我花了时间，肯定得到了回报。使用JDO或JPA，您可以以最少的更改来更改供应商（JPA具有orm映射，因此我们谈论更改供应商的时间少于一天）。如果像我这样有100多个桌子，这是巨大的。另外，您还将获得内置的缓存以及集群智能缓存逐出功能，这一切都很好。SQL / Jdbc适用于高性能查询，但透明持久性在编写算法和数据输入例程方面要好得多。我的整个系统中只有大约16个SQL查询（超过5万行代码）。
任何说JDO已死的人都是一个令人沮丧的FUD贩子，他们知道这一点。
JDO仍然健在。与更年轻，受约束的JPA相比，该规范仍然更强大，更成熟，更先进。
如果您希望仅使用JPA标准中提供的功能，则可以编写JPA并将DataNucleus用作比JPA其他实现更高性能，更透明的持久性实现。当然，如果您想要JDO带来的建模的灵活性和效率，DataNucleus也可以实现JDO标准。
我本人一直在研究此问题，因此找不到两者之间的重大区别。我认为最大的选择是使用哪种实现。对于我自己，我一直在考虑DataNucleus平台，因为它是两者的数据存储不可知的实现。
我在同一项目中使用了Hibernate（JPA实现）和JPOX（JDO实现）。JPOX可以正常工作，但是很快就遇到了bug，那里是当时不支持的Java 5语言功能。在与XA事务配合时，存在一些问题。我从JDO对象生成数据库架构。它想每次都连接到数据库，这很烦人，如果您的Oracle连接不起作用。
然后，我们切换到休眠状态。我们只是使用纯JPA玩了一段时间，但是我们需要使用某些Hibernate特定功能来进行映射。在多个数据库上运行相同的代码非常容易。Hibernate似乎主动地缓存对象，或者有时只是具有奇怪的缓存行为。Hibernate无法处理一些DDL构造，因此它们在运行用于初始化数据库的其他文件中定义。当我遇到一个Hibernate问题时，通常会有很多人遇到相同的问题，这使搜索解决方案变得更加容易。最后，Hibernate似乎设计合理且可靠。
其他一些响应者建议仅使用SQL。对象关系映射的真正杀手级用例是测试和开发。为处理大量数据而建立的数据库通常很昂贵，或者很难安装。他们很难测试。有很多内存中的Java数据库可用于测试，但通常对生产无用。能够使用真实但有限的数据库将提高开发效率和代码可靠性。
我在2012年5月制作了一个使用JDO 3.0和DataNucleus 3.0的示例WebApp-看看它有多干净： https //github.com/TorbenVesterager/BadAssWebApp
好的，也许有点太干净了，因为我将POJO同时用于数据库和JSON客户端，但这很有趣:)
PS：包含一些SuppressWarnings注释（在IntelliJ 11中开发）