Pourquoi est-ce que j'obtiens UnsupportedClassVersionError dans jnlp?

Question

Je reçois un UnsupportedClassVersionError lancé lors du lancement de jnlp, mais quand j'essaie d'exécuter les fichiers jar pertinents à partir de la ligne de commande tout fonctionne bien. J'ai essayé de mettre les versions j2se à 1.5+, 1.6+, en utilisant des fichiers jar signés/non signés, mais tout cela n'aide pas.

J'essaie de lancer mon propre fichier jar avec deux fichiers jar de support (mysql-connector.jar et swingx.jar). Mon fichier jar a été compilé avec 1.6 paramètres de conformité dans Eclipse et construit dans un pot avec fourmi. Depuis que je peux lancer les 3 jars de la ligne de commande en utilisant Java 1.6, je suis un peu déconcerté que jnlp échoue. Toute aide est appréciée.

Voici le fichier jnlp:

<?xml version="1.0" encoding="utf-8"?> 
<!-- JNLP File --> 
<jnlp spec="1.5+" codebase="http://www.etc.com/p" href="demo-daily.jnlp"> 
<information> 
    <title>demo: daily stock charting utility</title> 
    <offline-allowed/> 
</information> 
<security> 
</security> 
<resources> 
    <j2se href="http://java.sun.com/products/autodl/j2se" version="1.6+" /> 
    <jar href="demo-daily.jar" main="true" /> 
    <jar href="swingx.jar" main="false" /> 
    <jar href="mysql-connector.jar" main="false" /> 
</resources> 
<application-desc main-class="quipu.viewers.charts.stockcharts.daily"/> 
</jnlp> 

L'erreur que je reçois est:

java.lang.UnsupportedClassVersionError: numéro de version dans le fichier Bad .class à java.lang.ClassLoader.defineClass1 (Procédé natif) à java.lang.ClassLoader.defineClass (ClassLoader.java:675) à java.security.SecureClassLoader.defineClass (SecureClassLoader.java:124) à java.net.URLClassLoader.defineClass (URLClassLoader.java:260) sur java.net. URLClassLoader.access $ 100 (URLClassLoader.java:56) à java.net.URLClassLoader 1.run $ (URLClassLoader.java:195) à java.security.AccessController.doPrivileged (Native Method) à java.net.URLClassLoader.findClass (URLClassLoader.java:188) à com.sun.jnlp.JNLPClassLoader.findClass (JNLPClassLoader.java:256) à java.lang.ClassLoader.loadClass (ClassLoader.java:316) à java.lang.ClassLoader.loadClass (ClassLoader.java:251) à com.sun.javaws.Launcher.doLaunchApp (Launcher.java:1052) à com.sun.javaws.Launcher.run (Launcher.java:105) à java.lang.Thread .run (Thread.java:613)

Answer 1

D'abord, ouvrez une fenêtre CMD ou une fenêtre shell (en fonction du système d'exploitation que vous utilisez) et tapez ceci:

java -version 

à Assurez-vous que la version que vous utilisez est la version que vous prévoyez d'exécuter. Puis, à nouveau de la ligne de commande, exécutez la commande suivante:

javaws http://host/path/to/your.jnlp 

Si vous ne pouvez pas exécuter javaws de la ligne de commande, vous devrez savoir où il est installé et utiliser le chemin complet vers l'exécutable. Sous Windows, ce sera quelque chose comme

C:\Program Files\Java\jre1.6.0_14\bin\javaws.exe 

et sous Linux, il peut être /usr/bin/javaws ou il peut être dans un autre répertoire.

Je sais que sous Windows, en tout cas, lorsque vous exécutez une application Java Web Start, le chargeur JNLP est utilisé à partir de la version Java la plus récente installée. Ou du moins c'est censé faire ça. Je n'ai pas expérimenté sous Linux (ou MacOS) pour voir comment cela fonctionne. Mais il est toujours possible que quelque chose ne fonctionne plus et lorsque vous lancez un JNLP, vous exécutez accidentellement un lanceur Java 1.5 JNLP.

Vous pouvez toujours essayer de désinstaller et de réinstaller la version la plus récente de Java pour vous assurer que la version la plus récente et la plus performante est correctement installée. Cela peut réparer les choses. Vous pouvez également vérifier votre $ PATH (ou% PATH%) pour vous assurer que la version correcte de Java est sur le chemin. (Ce n'est pas toujours nécessaire ... mais si une version de Java est sur le chemin, assurez-vous que c'est la version que vous voulez.) Vérifiez la variable d'environnement JAVA_HOME pour vous assurer qu'elle pointe là où vous le pensez.

Answer 2

Juste une supposition, mais mettre à jour le balise d'ouverture de spécification de référence = « 1.6+ »

<jnlp spec="1.6+" codebase="http://www.etc.com/p" href="demo-daily.jnlp">