Blog#9

GWT peut-il survivre sans Hibernate ?
Lors de nos débats actuels (vous savez, ces longues palabres techniques et enflammées où chacun campe sur ses positions ;) ) sur la libraire Google, la gestion des proxy Hibernate a une place de choix.
Au-delà des octets se pose une question de fond : à quel point une librairie émergeante doit-elle supporter des standard de marché pour être s’imposer ?
Attardons-nous quelques instants sur la question.
Son sens n’est pas de savoir si une nouvelle librairie doit fonctionner avec les milliers de lignes de code existantes de par le monde. Il semble relativement évident que toute nouvelle technologie qui nécessiterait de faire table rase de l’existant, tant au niveau formation que code produit, serait vouée à l’échec, si géniale soit-elle. Les enjeux économiques autorisent une évolution technique, pas une révolution.

Non, l’élément important est plutôt de savoir à quel point elle devrait être compatible avec l’existant… La gestion des proxies en est une assez bonne illustration : GWT doit-elle les prendre en charge, en sérialisant les objets Hibernate en JavaScript ?
Pour ma part, j’y vois plusieurs objections :

• Il ne me semble pas du ressort d’une librairie de présentation de gérer les artefacts de sa consœur qui gère l’accès aux données
• Pourquoi supporter Hibernate, et pas TopLink, JDO, Spring, JackRabbit, [insérez ici votre librairie préférée], … ?
• Le mécanisme de proxies n’est pas standardisé. Non seulement un tel développement serait donc spécifique à Hibernate, mais il serait lié à une implémentation particulière (version) de la librairie de persistance !

Inversons maintenant la question : Hibernate doit-il supporter GWT ? En fait, je trouverai assez naturel qu’Hibernate propose un mécanisme de « déproxification » des objets qu’il gère, pour répondre au besoin des Objets qui transitent entre plusieurs machines virtuelles. Cela recouvre à la fois le cas de GWT (si on considère que la librairie fonctionne sur une machine virtuelle Java écrite en JavaScript), mais aussi la sérialisation/désérialisation XML ou l’envoi sur JMS.

Au final, il est probable que GWT et Hibernate continuent à évoluer dans leurs sphères respectives. La « glue » entre l’un et l’autre reste pour l’instant une problématique à la charge de l’application. Nul doute que l’usage fera émerger rapidement de bonnes pratiques qui permettront de marier efficacement deux technologies majeures mais qui ont parfois du mal à cohabiter.

LazyKiller : le retour
Et pourtant, tout n'est pas perdu B) ! J'ai mis au point une petite librairie (en fait, plutôt une preuve de concept) permettant d'utiliser des objets du Domaine Hibernate partiellement chargé dans la couche de présentation GWT (et de les réinjecter dans le code serveur).
Pour les plus courageux d’entre vous, j’ai écrit un long article qui explique les problèmatiques rencontrées, celles résolues et les limitations actuelles. Bonne lecture !