Blog#9

Pour un nouveau développement, vous préconiseriez plutôt d’utiliser Hibernate ou JPA ?
De prime abord, la question peut sembler étrange tant Hibernate semble avoir inspiré le standard Java Persistence API. Les technologies sont même tellement proches qu’un tel choix s’avère presque paradoxal : après tout, Hibernate est une implémentation de JPA, cela revient donc à comparer un Coca et un Coca light ;)

De prime abord, JPA semble le choix évident. C’est en effet une API standard, et donc interchangeable. Tout développement JPA fonctionne donc sans peine tant sur Hibernate que TopLink, OpenJPA, …
C’est tout ? Eh bien, oui, c’est tout ce que JPA apporte au monde Java.

Voyons maintenant ce qu’il enlève à un développement Hibernate.
En effet, JPA étant le plus petit dénominateur commun entre différentes librairies de persistance (Hibernate, TopLink, …), certaines fonctionnalités Hibernate ne font pas partie du standard et ne sont pas supportées par les autres implémentations (ou alors de manière tout aussi propriétaire).
On peut citer pêle-mêle (liste non exhaustive) :

• Les API Criteria et Example
• La gestion du flush manuel
• Mécanismes d’attachement et détachements d’objets
• Support des curseurs
• Filtrage dynamique des résultats
• Gestion du cache de second niveau
• Cascade « delete-orphan »

Certains seront tentés de coder les fonctionnalités « standard » avec l’API JPA, et de revenir à l’API Hibernate lorsque le besoin s’en fait sentir. Comportement assez étrange et hypocrite en fait, puis que le code s’en trouve tout de même lié à Hibernate ! Quitte à choisir une API, autant être cohérent sur toute l’application…

Autre point à prendre en compte : l’évolution. Le processus de strandardisation est généralement un travail de longue haleine, qui se chiffre généralement en mois et en années. Du coup, l’intégration des fonctionnalités Hibernate absente de JPA (ou de nouvelles) ne se fera sans doute pas avant la prochaine version, la JSR 313 (J2EE 6), prévue… fin 2008 !

En passant, il est intéressant que noter que la capacité d’innovation de Sun frise le zéro absolu : les dernières « révolutions » Java (JUnit, Struts, Hibernate, GWT,…) proviennent toutes du monde du logiciel Open-Source :>!

Et en attendant la JSR 313, que va faire Hibernate d’après vous ? Innover bien sûr !
A ce titre, la lecture de la FAQ Hibernate est assez éclairante :

Now that EJB 3.0 is out, is Hibernate dead?
Certainly not! We got involved in EJB 3.0 because we wanted to bring ORM technology to the masses. The EntityManager API defined by JSR-220 is just an alternative way to call Hibernate, from our point of view. We hope and expect that the standardization of ORM as a central, integrated piece of the J2EE platform will drive the next wave of adoption of ORM and Hibernate.
Because the standards process is an inappropriate place to innovate new functionality, and because it takes several years to validate a new idea and then work it into a final specification document, we will continue to develop and innovate our own APIs and use them to provide cutting edge features to those users for whom portability is not a major priority. For example, we are providing the cool new filtering functionality via the traditional Hibernate Session interface. In time, new features that prove sufficiently important will probably find their way into the EJB spec.

Clairement, Hibernate va continuer à évoluer (on pense notamment à Hibernate Shards ou Validator qui viennent d’être publiés récemment), et ces modifications ne seront intégrées à JPA que plusieurs mois ou plusieurs années plus tard.

Au vu de tels arguments, la question « Hibernate ou JPA » est sans doute plus difficile à trancher que de prime abord. L’interrogation centrale réside sans doute dans la cible du logiciel à développer : nécessite-t’il vraiment de fonctionner sur plusieurs implémentations de serveur d’application ? Vos développeurs peuvent-ils se passer des fonctionnalités propriétaires Hibernate telles que les Criteria, le réattachement, ou le filtrage dynamique ?

Des réponses à ces questions dépendront sans doute la préconisation adéquate…