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.
