La longue marche de JDOM 1.0
10/09/2004
Un peu plus de quatre ans après la première discussion entre les deux auteurs, JDOM conclut dix versions bêta par une version 1.0.
A l’automne 2000, Jason Hunter et Brett McLaughlin se rencontrent à Santa Clara lors d’une conférence O’Reilly. Ils échangent leurs frustrations quant à l’utilisation des API DOM et SAX, et décident alors d’en créer une pour les programmeurs Java désireux d’utiliser XML d’une façon très simple. JDOM est né. Jason Hunter, auteur de «Java Servlet Programming» et créateur du site servlets.com, s’occupera de la convivialité d’utilisation pour le programmeur Java. Brett McLaughlin, auteur de «Java and XML», aura la charge du respect de la conformité de l’API avec les spécifications XML.
Après deux versions bêta privées, JDOM bêta 3 devient disponible, le 27 avril 2000. JDOM n’étant pas un produit commercial, la guerre des versions l’épargne. L’API continue donc sa route des versions bêta, incluant toujours plus de fonctionnalités et se répandant largement dans la communauté Java. L’alternative aux spécifications DOM du W3C est d’ailleurs largement décrite dans nombre d’articles techniques liés à Java (javaworld partie 1 et 2 , ibm developerWorks , Oracle Technical Network – partie 1 , 2 et 3, xml.com, …) sur Internet mais également dans les ouvrages traitant de XML (comme Processing XML with Java par exemple). Par ailleurs, JDOM est intégré ou supporté par de plus en plus d’autres briques logicielles. Citons par exemple Saxon, le célèbre processeur XSLT/XPath ; Jaxen, un autre processeur XPath, eclipse, l’idée Open Source Java…
Si DOM est une spécification qui définit des concepts indépendants de toute mise en oeuvre et donc de tout langage, JDOM affiche une volonté claire de coller au plus près au langage Java, supprimant de fait de nombreuses lourdeurs inhérentes à DOM. Ce choix délibéré constitue le vrai succès de JDOM. Voici une liste (non exhaustive) de quelques différences :
- les éléments XML sont représentés par des classes concrètes et efficace pour le programmeur Java et non par des interfaces
- les noeuds XML peuvent être créés sans référence à un document DOM spécifique. Ils peuvent être rattachés à n’importe quel document par la suite
- la création des éléments (attributs, texte, …) XML en général est simplifiée et adaptée à Java, donnant un code réduit et plus lisible
- le déplacement d’un noeud XML (et donc de toute sa descendance) d’un document vers un autre est très simple. Avec DOM, cette manipulation est assez lourde et coûteuse puisqu’il faut demander au document devant accueillir le nouveau noeud d’en faire une copie…
- l’exportation de l’arbre XML dans un buffer ou dans un fichier de façon est aisée. C’est un des manques de DOM, manque qui sera comblé par l’implémentation des spécifications DOM 3 Load and Save (qui est encore un document de travail)
L’API de JDOM propose les fonctionnalités suivantes :
- création de document XML
- lecture de fichiers XML à partir de fichiers, arbres DOM, flux SAX (en réalité, JDOM ne fournit qu’une représentation sous forme d’objets Java, mais ce n’est pas un analyseur syntaxique. Il en utilise un, comme Xerces par exemple, pour la lecture de flux XML)
- exportation d’arbre XML JDOM sous la forme de fichier, arbre DOM, flux SAX
- transformation XSLT
- support de XPath 1.0 (à travers la brique logicielle Jaxen)
Alors si cette API fonctionne depuis longtemps et pour beaucoup de monde, pourquoi une version 1.0 si tardive ? Jason Hunter invoque trois raisons majeures : d’une part, la complexité de XML entraîne de longs efforts pour fournir une API conforme aux spécifications, d’autre part une fois la couverture des fonctionnalités indispensables à l’auteur lui-même atteinte, compléter les aspects dont il n’avait pas besoin ne le motivait que moyennement (d’autant de Brett McLaughlin a quitté le projet fin 2000). Enfin, JDOM est une JSR – soit une spécification Java (Java Specification Request) – soumise et approuvée par le Java Community Process (JCP). La gestion inhérente au processus JCP et la défense des idées de l’auteur face à Sun ont été si longues et fastidieuses qu’il a abandonné cette JSR-102. Par ailleurs, il reconnaît que la bêta 7 aurait pu déboucher sur cette la version stable 1.0, et qu’aujourd’hui il produirait la version 2.0. Mais l’API était sujette aux changements, et il a donc préféré garder ce statut de version temporaire pour quelques années de plus.
Malgré tout, JDOM, avec quatre années d’existence, reste bel et bien une alternative de poids au modèle DOM, et le nombre de développeurs convaincus croît sans cesse. Ces adeptes attendaient depuis longtemps ce changement de statut (question tellement récurrente sur la liste de discussion JDOM qu’elle fait partie de la FAQ !), pour pouvoir justifier l’intégration de la brique logicielle dans leurs projets. Après s’être intéressé à XQuery (création du site xquery.com) et le développement d’une suite de tests de conformité des processeurs XQuery (BumbleBee), Jason Hunter peut donc enfin effacer la mention bêta de JDOM, délivrer une version 1.0 largement éprouvée, et envisager la suite pour construire JDOM 1.1…
Autres articles :
Et sur d’autres sites :
- Chapitre 14 de Java et XML, et Chapitre 15 écrits par Elliotte Rusty Harold
- Le site Web de JDOM