15
votes

I have been moving around with this question and the bird eye difference between Hibernate SessionFactory and JPA EntityManagerFactory is that JPA is standard. You can use it without being afraid of underlying ORM. yet it calls the underlying sessionFactory under the hood.(Correct me if i am wrong)

But if someone knows that he has just to stick with hibernate as a ORM in the future, then what should he choose from these two Factories and why?

Secondly, what are the other differences between these two with respect to performance, features, stability etc?

1
Presumably the downvoter voted based on the fact that this question has been asked many times before on here, and simple search would tell you what you need to know (does it "take guts" to use search?). But then you'd have to ask them why ...Neil Stockton
So if i tell you that i did all search and i wanted to know about some specific aspects which were not asked in previous ones like performance n features of two. If u think the same question has been asked in exactly the same manner many times, mark and tell us the duplicate. But down voted means question that is not worth to post on SO, i believe. I know the worth and searched a lot about this on web.vicky

1 Answers

44
votes

You should prefer the standard JPA API over the proprietary Hibernate one, for several reasons:

  1. It makes you learn something that you can reuse in more other projects, relying on a different implementation
  2. The JPA API is cleaner than the Hibernate one: it doesn't have the early mistakes that the Hibernate API has
  3. The efforts and evolutions are now targeted at the JPA API. For example, the standard JPA2 criteria API is more complete than the old, proprietary, Hibernate Criteria API (but more complex to use, IMHO)
  4. If you want, you can always get the Hibernate Session from the JPA EntityManager. Not vice-versa

Anyway, most of the effort is in mapping the entities themselves, and that is done using standard JPA annotations, even when using the Session API.