Version imprimable
Bonjour,
J'ai utilisé plusieurs api de serialiastion tel que Simple, Xstream Jaxb, en java pour pourvoir persister les données xml sous format object, mais lorsque je compare les résultats de conversion je remarque que ca prend un peu de temps.
J'ai développé une petite lib fait maison qui utilise saxParser et je remarque que c'est beaucoup plus rapide a réaliser cette conversion xml/java bean que les api que j'ai cité plus haut.
Pouvez vous me dire l'intérêt d'utiliser ces différents API?
Les gens qui ne comprennent pas grand-chose à XML développent bien plus vite avec ce genre d'API de sérialisation, qui leur évitent de comprendre vraiment ce qu'ils font.
Personnellement, je pense que ça ne marche que dans des cas très simples, où XML n'est intéressant que parce que c'est ce que tout le monde fait, alors que ce serait plutôt le boulot de CSV ou .properties.
Mais de manière générale, je confirme : dès qu'on sait un peu ce que c'est XML, on va toujours bien plus vite en codant la sérialisation directement, qu'en essayant de s'intégrer avec ces API censées faire gagner du temps.
Il y a des exceptions, comme gson. Pas besoin d'intégration du tout, il fera une sérialisation automatique très simplement si on a juste des POJO à traiter. Mais bon, du coup c'est à peine plus élaboré que la sérialisation native de Java.
Bonjour,
Effectivement vous venez de confirmer ce que je pensais. Il me semble que ces API utilisent pour la plus part la Reflexion et les annotations , est ce que c'est lié au ralentissement du traitement de conversion?
Il y a également l'interface Serializable natif de java que je n'ai pas pu tester, simplement je voudrais savoir ce qu'il apporte de plus que les API externes
Merci de votre réponse.
D'accord je parlais de complètement autre chose.
Je croyais que tu parlais du temps pour développer le fonctionnel, pas du temps que le programme passe à sérialiser/désérialiser.
Les approches en SAX/Stax sont plus rapides que les libs que tu utilises, parce qu'elles font le traitement en ligne : elles lisent un peu de données et les traitent, puis passent à la suite.
Alors que les autres méthodes consistent à charger entièrement en mémoire le modèle XML, puis d'en faire quelque chose. Il peut arriver que ça revienne au même... Mais c'est rare. D'habitude ça veut surtout dire qu'on traite au moins deux fois les données, dans les deux sens. Normal que ce soit plus long.
En l'occurrence, c'est pas du tout ce dont je parlais. Moi je parlais du temps qu'on met pour programmer les choses. Je ne trouve pas que les bibliothèques de sérialisation/désérialisation automatiques soient pratiques. Mais celles qui chargent tout en mémoire, ça je trouve que c'est plutôt normal, ça simplifie tout, même si on perd en performances.
De plus ? Humm... Pas besoin d'intégrer encore une autre API externe, ça fait partie de Java de base, et géré par la plupart des bibliothèques tierces.Citation:
Envoyé par Rohan21
C'est aussi un peu plus compact que quoi que ce soit d'autre, et souvent un petit peu plus rapide.
... Mais à part ça, ça n'apporte pas grand-chose. C'est Java-only et pas intéropérable, ça résiste mal aux évolutions du programme, on manque de contrôle sur le flux de données généré.
Quand tu dit :Est ce que cela revient à utiliser DOM? puisque ce dernier créer un arbre xml et charge tout dans la mémoire.Citation:
Alors que les autres méthodes consistent à charger entièrement en mémoire le modèle XML,
C'est le même principe, en tout cas.
Ca dépende des api, mais oui, en général, elle travaillent en DOM. Le gros problème de la sérialisation, c'est les cross références (un objet référencé plusieurs fois), le gros boulot que vont t'éviter ces librairies:
-> T'emmerdéer à gérer ces cross-références dans des structures complexes
-> Stabilité dans le temps, même si tu change ton modèle de donnée, en général, tu est toujours capable de charger tes anciennes sérialisation.
Personellement, j'ai plutot travaillé avec xstream et, out of the box, il fonctionne sans la moindre intégration. Bien sur, faut apprécier avoir des noeuds xml à rallonge sans configuration :)