Débat : Avantages et inconvénients de JAXB pour la persistance de XML en Java

Le , par eclesia, Rédacteur
Bonsoir,

Je me pose beaucoup cette question depuis que j'ai eu a utiliser cette technologie pour "marshaller" et "unmarshaller" des objets sous differentes version xml.

JaxB a des avantages :
- lire et ecrire dans une vaste gamme de type d'entrée/sortie (Fichier, Flux, Noeud Dom ...etc...)
- Facilité d'utilisation.

Mais elle aussi de nombreux defauts :
- Utilisation d'annotations, ce qui oblige a alterer les classes d'origines (autrement dit impossible de l'utiliser sur une bibliotheque tierce)
- Reformatage des classes pour avoir soit des methodes get/set annotés ou des variables annotées

Et voici une liste de problemes auxquels je me suis confronté et n'ai pas pu trouver de reponses (meme en allant sur la mailing list officielle)

en version 1.0
@XmlElement(name="AnchorPoint", namespace="http://org.opengis/sld")
Resultat : <sld:AnchorPoint></sld:AnchorPoint>

en version 1.1
@XmlElement(name="AnchorPoint", namespace="http://org.opengis/se")
Resultat : <se:AnchorPoint></se:AnchorPoint>

JaxB ne permet pas d'avoir des classes annotés pour plus versions, plusieurs normes XML ou differents namespace. (exemple issu des normes OGC Styled Layer Descriptor version 1.0 et 1.1)

<Width>456</Width>
Un @XmlValue
OU
<Width><Literal>456</Literal></Width>
Des @XmlElement

Jaxb ne permet pas d'avoir des tags avec soit une valeur text soit des sous tags

Pas de mapping differencier.

Ce que j'entend par la c'est qu'il est impossible de faire en sorte d'avoir un objet se differencier en 2 ou N tag differents selon ses parametres.

Inefficace avec les interfaces.

Si on travail avec des interfaces, ce qui est une pratique souvent recommandé, il faut annoter toutes les implémentations qui existe.

Voila donc mon resenti vis a vis de cette technologie.
JaxB n'est utilisable que pour des mapping 1 pour 1 (ou presque), avec des variables de type primitif ou peu evoluer et pour une version unique d'une norme xml. Autrement dit il est inutilisable dans le cadre de projet voué a évoluer (changement des versions et normes xml impossible) et il est invasif dans le code source (annotations, refonte des classes avec des constructeurs sans arguments et autres ...)

En temps normal je ne dirais rien d'une api avec beaucoup de défaut, mais le fait qu'elle soit incluse dans la JRE me choque enormement. Elle aurait du exister en tant que librairie tierce mais pas etre imposer.

Qu'en pensez vous ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de oneLng oneLng - Futur Membre du Club https://www.developpez.com
le 29/01/2009 à 13:59
Citation Envoyé par hugo123  Voir le message
Je confirme la réponse plus haut, c'est justement ce que nous faisons dans notre application. Des Xsd sont lus au démarrage, nous générons des classes dans un répertoire puis les compilons et les importons dans le classloader courant.

Merci. Je vais regarder tout ça de très près.
Avatar de bugsan bugsan - Membre confirmé https://www.developpez.com
le 29/01/2009 à 16:07
J'utilise JiBX, qui permet d'avoir des Pojo sans annotations dont le bytecode est ensuite altéré pour y inclure le databinding. C'est à ma connaissance le plus rapide de tous, du à l'utilisation de StAX et de bytecode optimisé ...

Malheureusement, il n'est pas fourni avec un générateur de code correct, et le langage de mapping est un peu obscure (même avec la doc). C'est pourquoi j'en avais développé un moi même (un maven-plugin XSD => Pojo+config jibx associée). "wsdl2jibx" sur sourceforge.
Avatar de cisco cisco - Membre régulier https://www.developpez.com
le 29/01/2009 à 22:08
+1 pour JIBX qui permet de découpler le mapping de l'objet, ce qui est pratique pour pouvoir réutiliser des objets existant

+1 Pour JAXB pour les outils qui sont avec et qui permettent d'avoir vite un mapping, et -1 parce que c'est trop intrusif

XStream est xstreamement simple à utiliser, puissament customisable, et même si ce n'est effectivement pas du mapping mais de la sérialisation XML, il peut avantagement remplacer JAXB si l'on veut juste du XML en sortie
Avatar de natha natha - Membre expert https://www.developpez.com
le 05/02/2009 à 13:33
Hello,

J'utilise JAXB (inclut dans Java6 en version 2.1 maintenant contrairement à ce qui a été dit ci-dessus).

Code : Sélectionner tout
1
2
3
4
5
6
7
8
$ xjc -version 
xjc version "JAXB 2.1.3 in JDK 1.6"  
JavaTM Architecture for XML Binding(JAXB) Reference Implementation, (build JAXB 2.1.3 in JDK 1.6) 
 
$ java -version 
java version "1.6.0_10" 
Java(TM) SE Runtime Environment (build 1.6.0_10-b33) 
Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing)
Ceci dans le cadre d'un projet de synchronisation entre l'application et des serveurs fédéraux ou cantonaux (je suis en Suisse). Nous développons la partie client.

Il a énormément de xsd qui sont fourni dans la norme à implémenter et je ne me voyais absolument pas me taper le binding à la main. Ayant déjà utilisé JAXB dans le cadre d'utilisation d'un webservice, je l'ai également utilisé ici.
Le code généré est propre, facile à faire avec xjc, bien documenté (javadoc détaillant le schema). Faut juste se faire aux maxoccurs="unbounded" qui fait un code comme ça :
Code : Sélectionner tout
obj.getList().add(monObj)
Il faut bien sûr coder ce qu'il faut pour faire correspondre nos objets métiers aux objets utilisés dans le XML (des bêtes set(get())) mais avec la volumétrie, c'est du boulot.
Et quand les XSD changent de version, il faut regénérer le code et adapter. Mais bon, peu importe l'outil utilisé, quand les XSD changent, il y a toujours du code à adapter... Personnellement je préfère regénérer le code, voir les erreurs de compi dans Eclipse, et corriger, c'est assez facile.

Marshaller/unmarshaller est super facile.
Un défaut, la classe com.sun.xml.internal.bind.marshaller.NamespacePrefixMapper qui est dans le package com.sun ... pas top top pour l'utiliser proprement.

On peut personnaliser le prefix comme on le souhaite en fournissant une instance du NamespacePrefixMapper.

On peut placer les XSD où on veut sans avoir besoin de les modifier en utilisant org.w3c.dom.ls.LSResourceResolver (modifie l'emplacement du xsd).

La validation est facile à mettre en oeuvre.

Personnellement j'aime bien le principe d'avoir un code java pour mes XML totalement séparé de mon code métier, quitte à développer ce qu'il faut pour passer de l'un à l'autre. Annoter des classes existantes je trouve mal pratique, surtout que différentes classes pourraient être utilisées pour différents XML, ce qui deviendra impossible à maintenir efficacement.
L'idéal est effectivement d'avoir les XSD ou les faire, puis de générer le code.

Avis positif sur JAXB, et je trouve positif également que ça doit dans le JRE (car permet de l'avoir directement dans le JDK) et que c'est un outil efficace et simple pour l'utilisation de gros schema XSD.

Je sais également que le fournisseur de la version serveur de la norme que nous mettons en place utilise également JAXB 2.1 (Java5 par contre).
Avatar de hugo123 hugo123 - Rédacteur https://www.developpez.com
le 06/02/2009 à 10:23
Citation Envoyé par natha  Voir le message
Hello,

J'utilise JAXB (inclut dans Java6 en version 2.1 maintenant contrairement à ce qui a été dit ci-dessus).

Peut être que ca a effectivement changé en version supérieure, c'est une très bonne nouvelle si c'est le cas.

Cela faisait justement partie des principales critiques du fait d'ajouter jaxb dans la jdk :

http://www.florentgarin.org/blogs/in..._1_avec_java_6

et même l'un des principaux acteurs de jaxb en discute sur son blog :
http://weblogs.java.net/blog/kohsuke...ng_jaxbws.html

A moins que tu aies suivi la doc officielle de jaxb qui indique comment gérer ce problème ? :

https://jaxb.dev.java.net/guide/Migr..._JavaSE_6.html

en tout cas, même si j'apprécie jaxb, ca illustre bien le problème d'avoir inclus cette librairie dans le jdk.
Avatar de zolive zolive - Membre habitué https://www.developpez.com
le 06/02/2009 à 10:59
Savez vous s'il existe un tutoriel en français sur son utilisation ?
Ou un exemple simple qui depuis un fichier XSD
- génère les classes Java
- possède un marshaller vers un autre format de fichier que l'XML par exemple csv

et cerise sur le gâteau que ces classes java soient interfacées avec une IHM ?
Olivier
Avatar de lam7a lam7a - Futur Membre du Club https://www.developpez.com
le 06/02/2009 à 14:43
Citation Envoyé par zolive  Voir le message
Savez vous s'il existe un tutoriel en français sur son utilisation ?
Ou un exemple simple qui depuis un fichier XSD
- génère les classes Java
- possède un marshaller vers un autre format de fichier que l'XML par exemple csv

et cerise sur le gâteau que ces classes java soient interfacées avec une IHM ?
Olivier

L'outil pour générer les classes Java c'est XJC, il y a plein de tutoriel sur le net... Google it!!

Je ne connais pas de marshaller vers CSV...

Et je ne comprends pas très bien ta demande concernant l’interfaçage avec une IHM...
Avatar de kourkoul kourkoul - Membre du Club https://www.developpez.com
le 14/04/2009 à 22:55
Bonjour,

J'ai pas mal utilisé jaxb dans le développement. C'est un outil de bonne qualité, toutefois je pense que son intégration dans JDK/JRE n'est pas complètement justifié pour des raisons d'incompatibilité entre différentes versions de JAXB.

Pour résumer les avantages que je vois au JAXB:
- facilite d'utilisation dans les cas les plus courants (les opération de génération de classes, unmarshal, marshal sont extrêmement simples)
- un bon support de schéma XML (J'ai évalué et abandonné d'autres solutions comme XMLBeans et Castor pour des raisons de mauvais support de schéma)

les inconvénients sont, pour ma part :
- il est difficile (mais possible) de conserver les commentaires/formatage du fichier XML lors du cycle unmarshal/marshal. Toutefois ce problème est inhérent au data-binding.
- les classes générées varient selon la version de JAXB, et comme les versions de JAXB varient avec les versions de Java .. la maintenance des couches de gestion de données peut devenir compliquée.

Pour conclure, je trouve que JAXB est quasiment un passage obligé si vous voulez faire du data-binding pur en Java (surtout si vous partez d'une XSD). En revanche si vos clients vous demandent de conserver le formatage/commentaires des fichiers XML et/ou la durée de vie de votre appli est relativement importante, le choix est beaucoup moins évident.
Avatar de lespoches lespoches - Membre habitué https://www.developpez.com
le 13/05/2009 à 15:34
Eh Eh tip top le sujet, je suis actuellement en plein dans le sujet.

Je viens d'arriver sur un projet où EMF a été utilisé pour faire le dataBinding
Le client est codé en RCP et se base sur ces classes (modèle 1).

Coté serveur, on recoit nos objets via WebServices mais le modèle (modèle 1) ne comportait pas d'information de mapping necessaire à hibernate pour la persistance. Une solution existe "Teneo" mais celà générer des informations de mapping à la Xdoclet dans les commentaires (pas trop JPA tout ca)

++ JAXB/HyperJAXB3
Je me suis penché donc sur d'autres solutions telle que JAXB pour la partie serveur et sur les solutions permettant d'ajouter une couche de persistance sur les objets générés et j'ai trouvé Hyperjaxb3.

Assez puissant et très facile a mettre en oeuvre.
Cette solution devrait être retenu après avoir pousser les tests un peu plus loin.

Un -- pour JAXB (corriger moi si je me trompe) qui ne génère pas de code pour gerer les minInclusive et maxInclusive dans le setter.
Il semblerait que ce soit quand meme gérer lors de la sérialisation/désérialisation de l'objet..

Voilou vlalou !
Avatar de bugsan bugsan - Membre confirmé https://www.developpez.com
le 20/06/2009 à 4:10
Je trouve cela vraiment dangereux d'utiliser des classes générés en tant que pojo de persistance.
Avatar de vladimire vladimire - Membre régulier https://www.developpez.com
le 17/11/2010 à 15:03
Une discussion très intéressante qui m'a aidé dans mon BenchMarking...
Offres d'emploi IT
Consultant sap finance/controlling H/F
Safran - Ile de France - Vélizy-Villacoublay (78140)
Ingénieur H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Responsable bénévole de la rubrique XML : Didier Mouronval -