Là où ça se complique, c'est que JPA 2.0 définit (entre autre) de nouvelles méthodes dans l'interface PersistenceUnitInfo, référençant des enums propres à JPA2. Et Spring, pour faire sa cuisine interne, utilise un décorateur autour de cette interface (faut dire, c'est fait pour !)
Le décorateur de Spring doit rester compatible JPA1. Le simple fait d'importer les enums JPA2 casserait cette compatibilité. Résultat: Spring 3.0.0 n'est pas compatible avec Hibernate 3.5-Beta3 et plus :'(
Rassurez-vous, Spring 3.0.1 va corriger le problème, via un proxy construit à la volée si JPA2 est détecté et je vous passe les détails, mais avouez que c'est ballot de se coltiner ce genre de problème sur un changement d'API.
Qu'est ce qu'il aurait fallu faire ?
Peut être définir une nouvelle interface PersistenceUnitInfo2 pour étendre PersistenceUnitInfo ? Pas très joli mais au moins la compatibilité aurait été plus facile à gérer pour les développeurs de middlewares.
Erreur de jeunesse ? Pensez-vous ! On a déjà eu le coup avec javax.sql.Connection lors de l'introduction des Savepoint de JDBC 3. Le build de commons-dbcp doit se tapper une mise en commentaire d'une partie du code pour produire la version JDBC 2, et a du remettre ça avec JDBC 4 !
3 commentaires:
pour faire sa cuisine interne :)
Dans la même veine, je garde en tête un bon article d'Eugene (euxx) à propos de rétro-compatibilité : comment gérer l'appel de plusieurs versions différentes d'une même API.
@++
oups, faut vraiment que je prenne l'habitude de me relire ;)
Enregistrer un commentaire