Discussion :

[LGnord]

Bonjour,

J'utilise un jar que je n'ai pas écrit. Lorsque je l'utilise au moment du runtime, j'ai le message suivant:

java.lang.NoSuchMethodError: javax.xml.stream.XMLInputFactory.newFactory()Ljavax/xml/stream/XMLInputFactory;

Une recherche me montre que cette méthode (XMLInputFactory) existe dans Java 6 mais pas dans Java 5:

Je suis surpris car l'erreur est dans le package javax. A ma connaissance, ce package est stable et commun à toutes les JVMs (dans mon cas Open JDK 1.6).

Quelqu'un saurait-il me dire ce qu'il en est ?

Merci d'avance pour votre aide.

[thelvin]

Je suis surpris car l'erreur est dans le package javax. A ma connaissance, ce package est stable et commun à toutes les JVMs (dans mon cas Open JDK 1.6).

Et alors ? Ça n'interdit pas d'ajouter de nouvelles choses aux nouvelles versions... Java 6 est sorti après Java 5.

Il est probable que tu aies compilé le code avec un jdk 1.6 en demandant la rétrocompatibilité 1.5, mais que tu essaies de lancer le .jar avec un jre 1.5.
Du coup, il n'y a pas de problème de bytecode, mais 1.5 a toujours moins de choses dans sa bibliothèque de base que 1.6 n'en a.

[LGnord]

Merci pour ta réponse que je vais essayer de reformuler:

Le*.jar a été compilé avec Java 6 (du coup la méthode existe à la compilation) mais le byte code généré est 1.5 (rétrocompatibilité 1.5).

Par conséquent à run-time, et même avec une jvm 1.6, la méthode n'existe pas (car le byte code est 1.5).

Est-ce bien cela? Et si oui, comment éviter le problème?

Voici comment je compile:

Code :

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

1
2
3
4
javac -d ./bin -cp ... Main.java >> $log
 
javac -version
javac 1.6.0_22

Voici comment j’exécute:

Code :

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

1
2
3
4
5
6
java -cp ./bin:... Main >> $log
 
java -version
java version "1.6.0_17"
OpenJDK Runtime Environment (IcedTea6 1.7.10) (rhel-1.21.b17.el5-x86_64)
OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)

Dans les deux exemples ci-dessus les '...' représentent mon classpath et rien de plus.

[tchize_]

Par conséquent à run-time, et même avec une jvm 1.6, la méthode n'existe pas (car le byte code est 1.5).

Est-ce bien cela?

Non, si la jvm était capable de faire ce genre de détection (autrement dit si les .class de l'api avaient pour chaque méthode "disponible pour byte code XXX", le compilateur pourrait déjà t'avertir que c'est impossible de compiler pour java 1.5


D'abord:
si la méthode n'existe pas pour java 5, il n'y a aucune raison d'utiliser la retro compatibilité à la création du jar.
le message indique que la méthode n'est pas disponible alors que la javadoc dit le contraire. Je vois plusieurs possibilités à ça

1) icedtea est buggé -> tester avec un jvm oracle pour vérifier cette hypothèse
2) le classpath de icedtea et été bidouillé d'une manière ou d'une autre et pointe vers le classpath d'une jvm 1.5 -> vérifier la variable d'environnement CLASSPATH (idéalement la supprimer), au besoin réinstaller icedtea
3) un des .jar que tu fournis à ton application dans ton -cp contient une vieille implémentation de javax.xml.stream.XMLInputFactory qui n'a pas cette méthode -> vérifier tes librairies faisant partie de -cp. Un simple grep javax.xml.stream.XMLInputFactory *.jar te listera tous les jar qui embarquent cette classe. Idéalement, il ne devrait en trouver aucun.

[LGnord]

Merci pour ton aide. J'ai résolu mon problème.

1.
Mon code fonctionne avec une autre JVM:

Code :

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

1
2
3
4
../jdk1.7.0/bin/java -version
java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode)

C'est du java 1.7, mais je pense que cela n'est pas grave.

2.

Code :

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

echo $CLASSPATH

La variable CLASSPATH n'est pas affectée. Cette piste est ecartée.

3.

Code :

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

1
2
grep javax.xml.stream.XMLInputFactory *.jar
Fichier binaire saxon9he.jar concorde

Il y a potentiellement un piège.

Pour conclure, mon problème est résolu. Par ailleurs, y-a-t-il un moyen de vérifier/signaler à OpenJDK la difficulté que j'ai rencontrée?

[tchize_]

vue le 3, je pense pas qu'ils soient responsables. Cherche une version de saxon n'embarquant pas XmlFactory pour résoudre définitivement ton problème.

[LGnord]

Encore merci pour ton aide.

J'ai une autre question. Dans mon classpath, je n'explicite pas les *.jar de javax. Ils sont donc 'automatiquement' trouvés par Java. Y-a-t-il des règles de priorité qui explicite dans quels ordres les classes sont choisies?

[tchize_]

la règle est que le classloader délegue d'abord au parent avant de chercher lui même. Donc on va aller chercher au coeur de la jvm avant de chercher dans les jar fournis. ce que icedtea sembe ne pas avoir fait.


Mais cette règle n'est pas absolue. En environnement J2EE, la règle est l'inverse (local puis seulement parent) sauf pour les classes du bootstrap

[LGnord]

J'ai parcouru le contenu de saxon9he.jar.

Leur code utilise XMLInputFactory. Mais ne le redéfini pas. En effet, le package javax.xml.stream n'existe pas.

Je suis donc persuadé que l'implémentation de Open JDK contient une version incorrecte de javax.xml.stream.XMLInputFactory.

Dans tous les cas, 1000 mercis pour votre aide.