Fans of the Hibernate object-relational mapping (ORM) framework will realize that the Java Persistence API (JPA) is basically a standardization of that framework. And, if you're like me, you really haven't given much thought to JPA, because, gee, isn't it just a watered-down Hibernate? Maybe, maybe not. (I'm not going to get into that here and now.)

It can be useful, though (even if only politically or procedurally), to code to JPA instead of the Hibernate API. If you find yourself in that situation, you may find this compare/contrast between the two API's to be useful:

Hibernate JPA
SessionFactory EntityManagerFactory
Session EntityManager
sessionFactory.getCurrentSession().[method]() entityManager.[method]()
saveOrUpdate() persist()
Query.setInteger/String/Entity() Query.setParameter()
list() getResultList()
uniqueResult() getSingleResult()
uniqueResult() returns null getSingleResult() throws NoResultException
CriteriaQueries - yes CriteriaQueries - no

Additionally, there are a couple Hibernate-specific JPA-isms to keep in mind:

  • If the underlying JPA implementation is Hibernate, either/both annotations or/and mapping files may be used - at the same time. In such a situation, I believe the mapping files act as an override for the annotations.
  • The best of both worlds (in my mind) is to base the code (at an interface- or API-level) on JPA and its EntityManager, but to have the implementation interact with the Hibernate Session, which can be obtained by calling getDelegate() on the EntityManager.