Discussion :

[Mickael Baron]

La spécification JPA (Java Persistence API) décrit comment mapper des objets Java avec une base de données relationnelle.

Différentes implémentations existent pour cette spécification et sans être exhaustif les plus connues sont

• Hibernate
• EclipseLink
• OpenJPA
• Autres ...

Quelle(s) implémentation(s) utilisez-vous actuellement ? Partagez également votre expérience.

[Mickael Baron]

J'ai voté Hibernate puisque je l'utilise bien avant que la spécification JPA apparaisse.

J'ai déjà joué avec Toplink (maintenant EclipseLink).

A noter qu'il m'arrive d'utiliser des annotations spécifiques aux implémentations.

Mickael

[Philippe Bastiani]

Pourquoi Spring Data JPA dans cette liste ? L'utilisation de Spring Data facilite l'écriture des DAO mais ne permet pas de s'affranchir d'une implémentation JPA !

[John.BE]

Pourquoi Spring Data JPA dans cette liste ? L'utilisation de Spring Data facilite l'écriture des DAO mais ne permet pas de s'affranchir d'une implémentation JPA !

eh pas sûr :/

J'ai voté Hibernate et EclipseLink.

J'ai commencé aussi sou Hibernate avant JPA .

[Mickael Baron]

Pourquoi Spring Data JPA dans cette liste ? L'utilisation de Spring Data facilite l'écriture des DAO mais ne permet pas de s'affranchir d'une implémentation JPA !

En effet, je crois que tu as raison. Je viens de regarder un peu plus dans les détails et il faut explicitement donner l'implémentation.

Je vais donc modifier le sondage

Merci

Mickael

[Philippe Bastiani]

En effet, je crois que tu as raison. Je viens de regarder un peu plus dans les détails et il faut explicitement donner l'implémentation.

Je vais donc modifier le sondage

Merci

Mickael

Perso, pour mes projets persos & professionnels j'utilise EclipseLink avec la surcouche Spring ou SpringData ! Ce dernier à l'avantage de formaliser les accès DAOs pour 90% des cas d'utilisations...

Pourquoi utiliser EclipseLink ?: le couple: implémentation de référence pour JPA + licence!

cdlt,
Philippe

[threshold]

Selon la version de JPA.

JPA 1 Hibernate, JPA 2 EclipseLink.
J'ai migré vers EclipseLink pour sa simplicité dans les cas "avancés" contrairement à Hibernate que je trouvais plus compliqué.

[wizaord]

Hibernate car fallait bien partir sur une implémentation au début. Et Hibernate me semble plus documenté sur Internet.

[natha]

J'utilise Hibernate. La raison ? A défaut d'autre chose... je ne connais les autres que de nom et Hibernate est l'implémentation "imposée" dans mon service.

Par contre j'évite d'utiliser l'implémentation. Tout est JPA. Je viens de découvrir Spring-Data et QueryDSL et ça a bien plus de valeur ajoutée.

[Heimdal]

Indifférent, nous utilisons l'implémentation du serveur JEE cible.

En cas de conteneur de servlets ou appli stand-alone, nous nous tournons vers Hibernate pour des raisons historiques.

[_skip]

Indifférent, nous utilisons l'implémentation du serveur JEE cible.

Et ça marche assez bien la portabilité entre les implémentations?

[fr1man]

J'avais constaté une différence au niveau des paramètres nommés des requetes natives.
J'utilisais avec Hibernate les : (:maVariable) alors qu'avec EclipseLink, il lui faut # (#maVariable).

[olivier.pitton]

Personnellement j'utilise EclipseLink en tant que "référence" et pour sa simplicité. Hibernate offre pas mal de choses intéressantes, mais peut cacher des boîtes noires quand on ne le connait pas assez.

[fablg]

Hibernate pour des raisons historiques avant tout.
L'avantage d'Hibernate est également une documentation très étoffée, notamment sur les forums.

[banitz]

J'utilise EclipseLink depuis un bout de temps et j'en suis très satisfait
Je suis en train de tester la version 2.4 avec le driver MongoDB

[zekzek]

J'avais fait un proto réalisé avec Mongo et Morphia, plutôt satisfaisant sur la simplicité.

Mais Morphia restant en v 0.99 depuis bientôt 1 an, et sans grande activité, je vais peut être me tourner vers EclipseLink (les quelques exemples se rapprochent de morphia en terme de simplicité).

A tester néanmoins avant de changer pour ElipseLink : les recherches géospatiales et autres subtilités natives de mongo, et la performance comparé à morphia.

[OButterlin]

L'intérêt de JPA est de s'affranchir de l'implémentation... donc, syntax error pour moi

J'utilise l'implémentation liée au serveur d'application cible...
Hibernate sur JBoss
EclipseLink (il me semble) pour GlassFish

[Mickael Baron]

J'avais fait un proto réalisé avec Mongo et Morphia, plutôt satisfaisant sur la simplicité.

En fait tu souhaitais utilisait JPA pour un univers NoSQL ? J'ai remarqué que dans la prochaine version d'EclipseLink il y avait des annotations spécifiques pour le NoSQL. A noter qu'HibernateOGM se veut aussi un ORM pour le NoSQL.

Mickael

[Heimdal]

Et ça marche assez bien la portabilité entre les implémentations?

Je n'ai pas encore de retour pour OpenJPA qui est l’implémentation standard de Websphere et Weblo. Je devrais avoir des réponses dans les prochains mois avec un nouveau projet WAS 8.

En ce qui concerne Hibernate/EclipseLink, je n'ai pas clairement testé la portabilité (SSII oblige, on vise une seule cible), mais lors de l'implémentation je n'ai pas en tête avoir été confronté à des comportements différents. Bien entendu j'invite les développeurs a rester sur jpql/Criteria API et javax.persistence de partout.
Dans le cas contraire, la portabilité en prend forcement un coup.

[OButterlin]

...
Bien entendu j'invite les développeurs a rester sur jpql/Criteria API et javax.persistence de partout.
Dans le cas contraire, la portabilité en prend forcement un coup.

Clairement...

Je trouve ça assez naze d'ailleurs d'utiliser des annotations et/ou des instructions propriétaires dans ce contexte...
Même s'il faut reconnaître qu'il manque des petites choses qui seraient bien pratiques et des anomalies (peut-être liées à l'implémentation d'ailleurs)... j'en ai découvert une hier...