Any drawbacks of using Hibernate EntityManager (vs. Hibernate Core)?

Question

The Hibernate EntityManager documentation states, that:

You may use a combination of all three together, annotations without JPA programming interfaces and lifecycle, or even pure native Hibernate Core, depending on the business and technical needs of your project. You can at all times fall back to Hibernate native APIs, or if required, even to native JDBC and SQL.

Code that uses the JPA API (EntityManager) is clearly more portable (even with occasional fallbacks to Hibernate Core).

But would I have any advantages when using purely Hibernate Core? I wonder, if the JPA 2 model really fits on top of Hibernate Core without any contradictions? IOW, is a fallback to Core always easy and without problems?

My main concern is this:

Maybe the differences are not only in the API, but also in the underlying semantics?! (e. g. different transaction/versioning/locking semantics that may conflict: Pessimistic locking is mentioned in the Core documentation, but not in the EntityManager documentation - so could I still use pessimistic locking by falling back to Core without causing problems? Things like that...)

Answer 1

But would I have any advantages when using purely Hibernate Core?

If JPA 2.0 supports what you need, there is in my opinion no advantage at using Hibernate Core directly (and with JPA 2.0, the gap became more thin, making the need to fallback to Core the exception, not the rule, which is a very good thing).

I wonder, if the JPA 2 model really fits on top of Hibernate Core without any contradictions?

It does since JPA 1.0, the Hibernate developers created Hibernate3 with "JPA in mind" and adopted JPA semantics, defaults, etc in Hibernate3. You might want to listen to Gavin in this Tech Talk: Gavin King on Hibernate3 and EJB3:

In this tech talk King discusses how Hibernate3 builds upon and extends EJB3, addressing such topics as:

• New features of Hibernate3
• The relationship between Hibernate3 and the EJB3 container in JBoss
• What differentiates Hibernate3 from the EJB3 specification
• Hibernate's custom annotations available outside EJB
• The future of Hibernate

And according to my practical experience, the fact that Hibernate doesn't contradict with EJB 3 is true.

IOW, is a fallback to Core always easy and without problems?

Whether you use Core directly or not, you are using it (the EntityManager is a wrapper around the Session). So, yes, falling back to Core is easy if you really have to (for things that are still not in the spec like Query By Example, for example). And, no, this won't cause any problems (since you actually are using it, or a subset of it, in JPA).

Related questions

• Difference Hibernate 3.5 / JPA 2.0

Answer 2

It has been clear: depending on the business and technical needs of your project

But would I have any advantages when using purely Hibernate Core ?

Do not forget both Hibernate Annotations and Hibernate EntityManager is built on top of Hibernate core. So one more layer. Besides That, it rely on its mapping metadata stored in XML files. Some users prefer To use XML files instead of annotations because it leaves the domain objects completely independent of the DAO implementation you choose. But when using annotations, Hibernate with JPA book is clear

reduce your lines of code for mapping metadata, compared to the native XML files, and you may like the better refactoring capabilities of annotations

JDBC >> Hibernate core >> Hibernate Annotations

...

JDBC >> Hibernate core >> Hibernate EntityManager

And JPA 2 fits better what JPA 1 has not been provided. A lot of new features is now available such as

• Object oriented query API
• Wrapper's @Embeddable
• Collection of @Embeddables @ElementCollection

And so on...

Do not forget JPA EntityManager allows you retrieve its underlying vendor-specific provider by using getDelegate method if you need features where JPA does not provide.

Answer 3

I like using Hibernate Core directly. I also prefer XML mapping files.

I'm not really interested in using a secondary layer, to access Hibernate core functionality. As far as I am concerned portability in the persistence tier, is a complete non-issue.

There are very few real advantages of the JPA API over Hibernate API -- I saw people using JPA named queries (where Criteria would have probably been clearer & better), and the JPA annotations are somewhat better designed.

Other than that, JPA is just a layer adding complexity & potential overhead -- for no benefit. Architecturally in such a situation, the correct decision would be against using it.

Database portability OTOH is very real. I have custom allocators (generators) I use which are completely portable, and far more performant & simpler than the crazy mess which is the mis-designed Hibernate ones.

This approach has been very successful on multiple major commercial, Government & legacy database re-engineering projects. In short -- focus on what's important -- and an API on top of an API, is not it.