JDO的优点：
● JDO的生命周期状态机(lifecycle state machine)是正确的用法。任何其它的O/R映射工具都应该使用JDO的生命周期或者它的子集(例如：如果不支持事务)。记住，JDO生命周期是为JDO实现服务的。大部分用户不需要了解其中很复杂的内幕。网页Amber生命周期中有些图示。
● PersistentManager API对如何管理JDO对象的状态有一定的优势和价值。
JDO的缺点：
● 查询(query)支持不完全。它应该使用类似Hibernate的HSQL查询语言，并使用java.sql.ResultSet作为查询结果。
● 用于重载方法的字段扩展让人觉得比较混乱。最好使用类似Hibernate或者EJB/CMP的方法，并重载它们。
Hibernate的优点：
● 有着正确的数据模型。以POJO为基础的模型是个正确的方向。
● 可配置性(例如对象之间的关系)是个很好的基础。
● HSQL正是O/R映射语言应该有的。
● 有着完整的API
● 采用简明的Session类作为控制流的清洗器，因为它沿用了Connection的模型
Hibernate的缺点：
● 没有使用JDO生命周期，这是不正确的做法。
● API(例如查询)还是有点混乱。It's better than the alternative, but using java.sql.ResultSet as the foundation would clean it up.
● API如果作为一个规范的话，还是不够干净。例如，在使用查询参数(query parameters)时，存在一些应用漏洞。
● 我不认为使用类名作为表的标识是件好事。
EJB/CMP的优点：
● 采用工厂类(指Home)查找实例比向Session/Connection对象传递参数获取实例要好。
● ejbSelect跟上面说的类似。
● 查询名称使用abstract schma是一个很好的解决方案。
● 理论上来说，这种模式在某些方案中可以有更好的复用性。
EJB/CMP的优点：
● CMP不属于EJB规范。它并不是个合适的模型去实现这个目的。已经没有合适的(例如非官方)借口去让EJB3.0中保留CMP。
Amber优点：
● 使用JDBC ResultSet和PreparedStatement做查询
出于某些原因，O/R映射工具通常抛弃强大的ResultSet和PreparedStatement API，而创建自己一套并不是很合适的替代品。O/R查询器应该使用一个外部的SQL(例如HSQL)作为查询语言，并使用ResultSet作为结果集，使用PreparedStatement处理查询参数。可以增加其它的API作为查询子集，就像查询一个单独的实体，但应该使用ResultSet和PreparedStatement作为基础。
Amber缺点：
● Amber的研究价值远大于它的使用价值
原文内容：
JDO pros:
The JDO lifecycle state machine is the correct one. Any serious O/R mapper needs to use the JDO lifecycle or a subset (e.g. if transactions aren't supported.) Remember, the JDO lifecycle is for JDO implementors. Most users don't need to see the gory details. The Amber lifecycle page has some diagrams.
The PersistentManager API has some positives, valuable for managing the state of JDO objects.
JDO cons:
The query support is completely inadequate. It should use something like Hibernate's HSQL, and should use java.sql.ResultSet as the query result.
The promotion of fields to overloaded methods is messy. It's better to start with methods like Hibernate or EJB/CMP and overload them.
Hibernate pros:
The data model is correct. The POJO model using methods as the basis is the right way to go.
The configuration, esp for relations is a good basis.
HSQL is just about what an O/R map language should be.
The API is adequate.
The explicit Session makes the control flow cleaner, since it follows the Connection model.
Hibernate cons:
It doesn't use the JDO lifecycle model. This is incorrect.
The API, esp the query, is still a bit messy. It's better than the alternative, but using java.sql.ResultSet as the foundation would clean it up.
The API isn't clean enough for a spec, i.e. it has a number of implementation hacks, esp with the query parameters.
I'm not convinced using the class name as the table identifier is a good thing.
EJB/CMP pros:
The factory (home) classes are nice for finding instances rather than passing extra parameters to a Session/Connection object.
The ejbSelect is similarly
Using the abstract schema for the query names is a good solution
In theory, the model can allow for efficient object reuse in some cases
EJB/CMP cons:
CMP does not belong in the EJB spec. It's been contorted to follow a model that's not appropriate for the task. There's no valid, i.e. non-political, excuse for keeping CMP in EJB 3.0.
Amber pros:
Using the JDBC ResultSet and PreparedStatement for queries.
For some reason O/R mappers generally throw out the powerful ResultSet and PreparedStatement API and create their own hacked up and inadequate replacements. O/R queries should use an extended SQL like HSQL as the query language and use ResultSet for results and PreparedStatement for query parameters. Other specialized APIs can be added for particular subsets, like quering a single entity, but the foundation should be ResultSet and PreparedStatement.
Amber cons:
Amber is an experiment rather than an actual competing API.