So far, I always prefered to use Hibernate directly rather than JPA 1.0, because JPA was lacking some of the important features I needed and Hibernate provided: Criteria API, second level cache, unidirectional OneToMany and a few others.
Now, with the advent of JPA 2.0 and all the new features that come with it and that were initially missing in JPA 1.0 (http://en.wikibooks.org/wiki/Java_Persistence/What_is_new_in_JPA_2.0%3F), I wonder if there is still a need to use Hibernate directly.
What's your opinion? What's left in Hibernate 3.5 that I can't do with JPA 2.0 ?
Now, with the advent of JPA 2.0 and all the new features that come with it and that were initially missing in JPA 1.0 (http://en.wikibooks.org/wiki/Java_Persistence/What_is_new_in_JPA_2.0%3F), I wonder if there is still a need to use Hibernate directly.
Even for JPA 1.0, I would recommend a different approach: "JPA where you can, Hibernate where you must".
What's your opinion? What's left in Hibernate 3.5 that I can't do with JPA 2.0 ?
JPA 2.0 is very rich and I consider it as a huge improvement and many things that were requiring to use proprietary extensions are now standardized (see this previous answer).
But you might still need some Hibernate specific extensions in some situations: a custom UserType
, a non standard generator, a query by example, @Formula
, @Index
, etc. Have a look at the Section 2.4, “Hibernate Annotation Extensions” for more "examples".
But let me insist, I recommend to use JPA where you can, Hibernate where you must (the later part getting thiner with JPA 2.0).
On the EclipseLink Project we have been focusing on a strategy where users can stick to JPA as much as possible and we have been working to make our many advanced features easily available through extensions so that you can minimize your use of our native API. Obviously as the JPA reference implementation we need to be compliant but JPA offers several extension points that we make use of including query hints and persistence unit properties. Some features are enabled through EclipseLink JPA specific annotations and/or eclipselink-orm.xml as well as API but as noted with JPA 2.0 many of these can be handled by the standard configurations.
Ultimately the benefit is that by staying with the standard as much as possible you can leverage a common knowledge base as well as tooling and integrations. Advanced ORM capabilities are also very important but should only be needed in advanced cases and the usage should be well isolated with minimal coupling.
Doug
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With