Discussion :

[eclesia]

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 ?

[Shivan]

Personnelement j'utilise jaxb pour sa facilité et le gain en vitesse de développement. Je ne passe pas par les annotations. je créer un fichier XSD et à partir de ce fichier jaxb me génère les classes utiles.

Le plus gros problème que j'ai rencontré et de devoir instancié tout mon xml en mémoire avant de le marshaller. Mais devoir coder le parseur / formateur xml "à la main" serait vraiment une perte de temps. Donc je suis très mitigé.

[el muchacho]

Personnelement j'utilise jaxb pour sa facilité et le gain en vitesse de développement. Je ne passe pas par les annotations. je créer un fichier XSD et à partir de ce fichier jaxb me génère les classes utiles.

Le plus gros problème que j'ai rencontré et de devoir instancié tout mon xml en mémoire avant de le marshaller. Mais devoir coder le parseur / formateur xml "à la main" serait vraiment une perte de temps. Donc je suis très mitigé.

M'ouais, on peut faire la même chose avec Axis2 et XFire, si je ne m'abuse.

[Ricky81]

M'ouais, on peut faire la même chose avec Axis2 et XFire, si je ne m'abuse.

Sauf que le rôle d'Axis2 et XFire/CXF n'est pas de faire du DataBinding. En particulier XFire/CXF peut utiliser JAXB comme implémentation du DataBinding.

[Patriarch24]

Personnellement, j'ai essayé XStream, Castor et JAXB, et je préfère XStream. Couplé à Spring, on ne voit pas trop la différence, c'est philosophique.
Je n'aime pas trop l'approche de JAXB, mais c'est un avis personnel. C'est pour ça que j'ai répondu : j'attends de voir comment ça évolue.

[hugo123]

Sur un projet nous avons essayé castor et jaxb. Nous avons eu des soucis avec castor dont la validation était moins stricte que jaxb et dont l'API nous a déplu.
Pour notre cas d'utilisation jaxb s'est avéré très pratique à utiliser.

Pour détailler l'utilisation que nous en faisons :

* comme Shivan plus haut nous utilisons jaxb pour générer des classes à partir d'un xsd, ce qui du coup n'est pas génant pour la partie annotation car il s'agit de code généré.
* nous utilisons aussi jaxb pour générer des facades webservices au démarrage de l'application :

- une xsd avec des annotations jaxb définit le type d'objet à traiter
(les annotations jaxb dans la xsd ne sont dispos qu'a partir de la 2.1 si je ne me trompe pas)
- jaxb est utilisé pour créer des classes. Un plugin jaxb xjc utilise les annotations pour ajouter du comportement au classe généré (ajout d'interfaces et une méthode toJson par exemple)
- les classes sont compilées et montées dans le classloader courant
- un service générique expose ses méthodes qui sont entièrement définies par la xsd grace a xfire. La xsd est exposé dans le wsdl.

Bref, sans jaxb et les annotations, tout ceci aurait été impossible.

Edit : j'ai voté "Oui mais elle ne devrait pas etre incluse dans la JRE"
déjà parce que jaxb est inclus en version 2.0 dans la JRE 1.6 et que j'ai besoin de la 2.1. De facon générale je préfère quand les implémentations sont à part dans ce type de cas.

[sancelot]

bonjour,
je suis en veille sur le sujet depuis quelques semaines, apres avoir essayé de mettre en oeuvre castor sous linux, on se rend compte que c'est une galère .
ceci ne semble pas etre le cas avec jaxb

mon sujet de recherche est le suivant :
j'utilise un xsd pour génerer les classes permettant de manipuler ces données , principalement avec une interface graphique JTable, avec des fonctions de persistance/marshall/unmarshall.

Cordialement,
S.Ancelot

[oneLng]

salut,

Nous utisons JAXB en production depuis +sieurs mois. C'est simple et ça fonctionne parfaitement. Nous sommes partis d'un XSD pour générer les classes java manipulant les messages XML. Ladite génération des classes s'est faite en ligne de commande avec XJC. Petite question : serait-ce possible d'effectuer la génération et utiliser les classes générées dans la même exécution du programme ?

Merci.

[moutonbreton]

Il y a quelques mois j'ai eu l'occasion de tester quelques produits cités ici. Je précise que je recherchais avant tout un outils de permettant de générer du code Java à partir d'un schéma XML.

JAXB : très bon support XML Schema dans les dernières versions. La possibilité offerte de contrôler la génération des classes par l'intermédiaire d'annotations dans le schéma XML est des plus intéressante.

Castor : support insuffisant du XML Schema (pas de support du type xs:anyType par exemple).

XMLBeans : je m'étonne que personne ne l'ai encore cité. De ce que j'ai pu voir, l'outil qui offre le meilleur support XML Schema. J'ai beaucoup apprécié également la possibilité de "naviguer" dans mes objets avec des requêtes XPATH ou XQuery. L'outils atteint ses limites lorsqu'il s'agit d'unmarshaller un XML volumineux. Mais effectuer un pré-traitement StAX sur le XML pour unmarshaller morceau par morceau permet de contourner se problème.

XStream : l'outils le plus simple d'utilisation mais pas vraiment un outils de databinding XML à mon sens. Il n'offre pas la possibilité de générer des classes depuis un schéma XML. Le contrôle sur le XML généré à partir d'objet Java est assez limité. Je le qualifierais ainsi plutôt d'outils de sérialisation/désérialisation.

[moutonbreton]

Petite question : serait-ce possible d'effectuer la génération et utiliser les classes générées dans la même exécution du programme ?

C'est sûrement possible. C'est ce que fait je pense GroovyWS :

http://groovy.codehaus.org/GroovyWS

[hugo123]

Petite question : serait-ce possible d'effectuer la génération et utiliser les classes générées dans la même exécution du programme ?

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.

[lam7a]

J'utilise aussi JAXB, jusqu'à présent j'en suis content.
Il est vrai qu'on a eu quelques problèmes au début, notamment cette histoire d'annotation dans les pojos... c'est pas très pratique. Maintenant on crée nos XSD (grâce a OracleXMLQuery) et on génère nos classes avec xjc (+plugin camelcase).
J'ai aussi quelques soucis avec le package-info et les préfixes de namespace...
Toutefois, je n'ai pas assez d'expérience avec les autres pour pouvoir réellement comparer.

J'ai une question qui vient de me traverser l'esprit en écrivant mon poste, il ressemblera à quoi mon pojo si j'utilise JAXB et disons Hibernate Annotations?

[oneLng]

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.

[bugsan]

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.

[cisco]

+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

[natha]

Hello,

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 - Visualiser dans une fenêtre à part

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).

[hugo123]

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.

[zolive]

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

[lam7a]

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...

[kourkoul]

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.