Comment réparer Java.lang.UnsupportedClassVersionError: Version major.minor non prise en charge
J'essaie d'utiliser Notepad ++ comme outil tout-en-un pour éditer, exécuter, compiler, etc.
J'ai JRE installé et ma variable de chemin d'accès a été configurée dans le répertoire .../bin.
Lorsque je lance mon "Hello world" dans Notepad ++, je reçois le message suivant:
Java.lang.UnsupportedClassVersionError: test_hello_world :
Unsupported major.minor version 51.0
at Java.lang.ClassLoader.defineClass1(Native Method)
at Java.lang.ClassLoader.defineClassCond(Unknown Source)
.........................................
Je pense que le problème ici concerne les versions; certaines versions de Java peuvent être anciennes ou trop récentes.
- Comment je le répare?
- Dois-je installer le JDK et configurer ma variable de chemin d'accès dans le JDK au lieu de JRE?
- Quelle est la différence entre la variable
PATHdans JRE ou JDK?
Le numéro de version indiqué décrit la version du JRE avec lequel le fichier de classe est compatible.
Les principaux chiffres rapportés sont:
Java SE 13 = 57,
Java SE 12 = 56,
Java SE 11 = 55,
Java SE 10 = 54,
Java SE 9 = 53,
Java SE 8 = 52,
Java SE 7 = 51,
Java SE 6.0 = 50,
Java SE 5.0 = 49,
JDK 1.4 = 48,
JDK 1.3 = 47,
JDK 1.2 = 46,
JDK 1.1 = 45
(Source: Wikipedia )
Pour résoudre le problème, essayez d’exécuter le code Java avec une version plus récente de JRE Java ou spécifiez le paramètre cible du compilateur Java pour lui demander de créer un code compatible avec les versions Java antérieures.
Par exemple, pour générer des fichiers de classe compatibles avec Java 1.4, utilisez la ligne de commande suivante:
javac -target 1.4 HelloWorld.Java
Avec les versions plus récentes du compilateur Java, vous aurez probablement un avertissement sur le chemin d'accès de la classe d'amorçage non défini. Plus d'informations sur cette erreur sont disponibles dans l'article de blog - Nouvel avertissement javac pour la définition d'une source plus ancienne sans chemin d'accès de démarrage.
Java.lang.UnsupportedClassVersionError se produit à cause d'un JDK plus élevé pendant la compilation et d'un JDK inférieur pendant l'exécution.
Dans Eclipse, je suis simplement allé dans la commande de menu Fenêtre -> Préférences -> Java -> Compilateur , puis définissez "Niveau de conformité du compilateur" sur 1,6.
Ne vous inquiétez pas, je l'ai résolu.
C'est en fait simple: vous devez installer BOTH JRE/JDK avec la même version.
JRE 6 -> JDK 6
JRE 7 -> JDK 7
Etc.
Cette erreur signifie que vous essayez de charger un fichier "classe" Java compilé avec une version de Java plus récente que celle que vous avez installée.
Par exemple, votre fichier .class aurait pu être compilé pour JDK 7 et vous essayez de l'exécuter avec JDK 6.
La solution consiste donc à:
- Mettez à niveau votre environnement d'exécution Java ou
Recompilez la classe si vous avez le source, en utilisant votre compilateur Java local (si vous en avez un).
javac NomFichier.Java
Pour les développeurs, cela peut arriver si un autre développeur vérifie un fichier .class et qu'ils ont une version de Java plus récente que la vôtre!
Vous essayez d'exécuter votre programme avec une version de Java qui ne prend pas en charge la version dans laquelle le code a été compilé. Donc, en gros, vous devez avoir compilé votre code avec une version supérieure et essayer de l'exécuter en utilisant une version inférieure.
Comme vous obtenez
Unsupported major.minor version 51.0
et la version 51.0 correspond à J2SE 7 vous avez probablement compilé votre code en Java 7 et avez essayé de l'exécuter avec une version inférieure. Vérifiez ce que Java -version affiche. Ce devrait être la version Java 7. Sinon, apportez les modifications appropriées dans PATH/Java_HOME. Ou vous pouvez compiler avec la même version que vous essayez d'exécuter le code. Si les configurations sont confuses, vous pouvez toujours donner le chemin absolu /home/user/jdk1.7.0_11/bin/javac et /home/user/jdk1.7.0_11/bin/Java.
J'ai eu une situation similaire sur Mac, et le processus suivant a fonctionné pour moi:
Dans le terminal, tapez
vi ~/.profile
Ajoutez ensuite cette ligne dans le fichier et enregistrez
export Java_HOME=/Library/Java/JavaVirtualMachines/jdk<version>.jdk/Contents/Home
où version est celui de votre ordinateur, tel que 1.7.0_25.
Quittez l'éditeur, puis tapez la commande suivante pour la rendre effective
source ~/.profile
Puis tapez Java -version pour vérifier le résultat
Java -version
Qu'est-ce que le fichier .profile?
Le fichier .profile est un fichier caché. C'est un fichier facultatif qui indique au système les commandes à exécuter lorsque l'utilisateur dont le fichier de profil est connecté se connecte. Par exemple, si mon nom d'utilisateur est bruno et qu'il existe un fichier .profile dans/Users/bruno /, tout son contenu sera exécuté lors de la procédure de connexion.
Dans le menu Eclipse Fenêtre -> Préférences -> Java -> Compilateur cochez également "Configurer les paramètres spécifiques au projet".
Si le problème persiste avec la même version de Java: essayez de supprimer manuellement le dossier de construction de votre projet. Puis redémarrez Eclipse.
Le problème le plus courant est une mauvaise configuration de votre variable Java_HOME qui doit pointer vers la bonne bibliothèque Java Development Kit, si vous en avez installé plusieurs.
Pour localiser le dossier du SDK Java, exécutez les commandes suivantes:
jrunscript -e 'Java.lang.System.out.println(Java.lang.System.getProperty("Java.home"));'
Debian/Ubuntu
Pour vérifier quel Java (openjdk) vous avez installé, vérifiez via:
dpkg -l "openjdk*" | grep ^i
ou:
update-Java-alternatives -l
Pour le changer, utilisez:
update-alternatives --config Java
Préfixe avec Sudo si nécessaire.
pour sélectionner la version Java alternative.
Ou vérifiez quels sont disponibles pour l'installation:
apt-cache search ^openjdk
Préfixe avec Sudo si nécessaire.
Ensuite, vous pouvez installer, par exemple:
apt-get install openjdk-7-jre
Préfixe avec Sudo si nécessaire.
Fedora, Oracle Linux, Red Hat
Installez/mettez à jour le paquet approprié via:
yum install Java-1.7.0-openjdk Java-1.7.0-openjdk-devel
Le package
Java-1.7.0-openjdkcontient uniquement l'environnement d'exécution Java. Si vous souhaitez développer des programmes Java, installez le packageJava-1.7.0-openjdk-devel.
BSD
Il existe un paquet OpenJDK 7 dans la collection de ports FreeBSD appelé openjdk7 qui doit probablement être reconfiguré.
Voir: Page wiki OpenJDK .
Les fenêtres
Installez simplement la bibliothèque appropriée du kit de développement Java SE à partir du site Oracle ou installez
Jenkins
Si vous rencontrez ce problème avec Jenkins, voir:
Cependant, sélectionner la bonne version de Java (plus récente) avec update-alternatives devrait fonctionner.
Vous pouvez avoir une bibliothèque JAR compilée dans Java 7 et vous n’avez que Java 6 en tant que Java Runtime. Cela pourrait arriver avec de nouvelles bibliothèques.
J'ai rencontré le même problème lorsque je travaillais avec un script Ant pour créer mon application.
J'utilise Eclipse pour le développement de mon application et j'ai changé la version du compilateur dans les propriétés de construction du projet. Mais cela n'a pas fonctionné pour moi. Ensuite, j'ai découvert que je pouvais fournir la version du compilateur dans le script Ant.
J'ai modifié le script Ant dans la section où il compile les fichiers Java.
<target name="build-Java" depends="prepare-build">
<echo message="Compiling Java files"/>
<javac ....
target="1.5"...
</javac>
</target>
Cela m'a permis de résoudre le problème mineur majeur non pris en charge.
J'ai eu le même problème avec un projet écrit en 1.7 et j'ai essayé de l'exécuter en 1.6.
Ma solution dans Eclipse:
Faites un clic droit sur votre projet propriétés -> chemin de construction Java -> bibliothèques
Sélectionnez votre bibliothèque système JRE et cliquez sur Modifier à droite, puis choisissez le JRE cible.
Allez maintenant à Compilateur Java sur la gauche et modifiez le niveau de conformité du compilateur en fonction de votre cible.
Cela a fonctionné pour moi.
Quand j'ai installé JDK 1.7, le problème a été résolu.
Comme plusieurs personnes l’ont répondu ailleurs, le programme Java est exécuté sur une version de Java plus ancienne que celle pour laquelle il a été compilé. Il doit être "compilé" pour assurer la compatibilité ascendante. En d'autres termes, il existe une discordance entre les versions Java source et cible.
La modification des options dans les menus Eclipse ne répond pas à l’affiche originale, qui a déclaré ne pas utiliser Eclipse. Sur OpenJDK javac version 1.7, vous pouvez compiler de manière croisée pour 1.6 si vous utilisez les paramètres -source et -target, et fournissez le fichier rt.jar -file de la version cible (c'est-à-dire la plus ancienne) au moment de la compilation. Si vous installez réellement la version 1.6 JRE, vous pouvez indiquer son installation (par exemple, /usr/lib/jvm/Java-6-openjdk-i386/jre/lib/rt.jar sous Ubuntu,/usr/jdk/jdk1. 6.0_60/jre/lib/rt.jar sur SunOS apparemment Désolé, je ne sais pas où il se trouve sur un système Windows). Ainsi:
javac -source 1.6 -target 1.6 -bootclasspath /usr/lib/jvm/Java-6-openjdk-i386/jre/lib/rt.jar HelloWorld.Java
Il semble que vous pouvez simplement télécharger rt.jar à partir d’Internet et le pointer dessus. Ce n'est pas trop élégant cependant:
javac -source 1.6 -target 1.6 -bootclasspath ./rt.jar HelloWorld.Java
Basé sur ceci...
J2SE 8 = 52
J2SE 7 = 51
J2SE 6.0 = 50
J2SE 5.0 = 49
JDK 1.4 = 48
JDK 1.3 = 47
JDK 1.2 = 46
JDK 1.1 = 45
Dans Eclipse, cliquez avec le bouton droit sur le projet dans l'explorateur de package:
Chemin de construction -> Configurer le chemin de construction
Sous:
Chemin de construction Java -> Bibliothèques -> Ajouter bibliothèque -> Bibliothèque système JRE -> JRE installés -> Rechercher .
Ajoutez le JRE requis en sélectionnant la bibliothèque dans la liste disponible une fois la recherche terminée.
Si vous utilisez Maven, définissez votre niveau de compilation Java. Ouvrez une ligne de commande et écrivez
Java -versionpour votre niveau de compilation:![Enter image description here]()
Si vous utilisez IntelliJ IDEA, sélectionnez projet → Fichier → Paramètres → Construire le déploiement d'exécution → Compilateur → Compilateur Java. Puis changez le code en octets 1.7 comme dans cette image:
![Enter image description here]()
Si vous rencontrez ce problème lorsque vous utilisez Maven , vous pouvez compiler votre code en utilisant le plug-in Maven Compiler .
<build>
<plugins>
<plugin>
<groupId>org.Apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.1</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
</configuration>
</plugin>
.....
UPDATE: définissez source et target sur 1.8, si vous utilisez JDK 8.
Comment je le répare?
Cette erreur signifie que le JRE utilisé pour exécuter votre code de classe ne reconnaît pas la version de Java utilisée. Généralement, la version de Java qui a généré votre fichier de classe (le compilé) est plus récente.
Pour résoudre ce problème, vous pouvez soit
a) Compilez vos sources Java avec la même version ou une version plus ancienne du compilateur Java utilisée pour l’exécuter. c'est-à-dire installer le JDK approprié.
b) Compilez vos sources Java avec la version la plus récente du compilateur Java mais en mode de compatibilité. c'est-à-dire utiliser le paramètre -target.
c) Exécutez vos classes compilées dans un JRE dont la version est identique ou plus récente que le JDK utilisé pour compiler les classes.
Vous pouvez vérifier les versions que vous utilisez actuellement avec javac -version pour le compilateur et Java -version pour le runtime.
Devrais-je installer le JDK et configurer ma variable PATH sur le JDK au lieu de JRE?
Pour la compilation, installez et configurez le JDK spécifique souhaité.
Pour l'exécution, vous pouvez utiliser celui fourni avec le JDK ou un JRE autonome, mais peu importe, assurez-vous que vous avez installé les bonnes versions et que vous avez configuré votre PATH de manière à éviter les surprises.
Quelle est la différence entre la variable PATH dans JRE et JDK?
La variable d’environnement PATH indique au shell de commande où chercher la commande que vous tapez. Lorsque vous tapez Java, l'interpréteur de commande examinera tous les emplacements spécifiés dans la variable PATH, de gauche à droite, pour rechercher l'exécutable d'exécution Java approprié. Si vous avez plusieurs versions de Java installées, c'est-à-dire que vous avez l'exécutable Java dans plusieurs emplacements spécifiés dans la variable PATH, la première que vous rencontrez en allant de gauche à droite est celle qui est exécutée.
La commande du compilateur est javac et vient uniquement avec le JDK. La commande d'exécution est Java et vient avec le JDK. Elle se trouve dans le JRE.
Il est probable que vous avez une version (51.0 = Java 7) de javac installée et que vous avez également la même version de Java installée, mais qu'une autre version précédente de Java apparaît plus tôt dans le PATH et est donc appelée à la place du celui que vous attendez.
J'avais le même message d'erreur lorsque j'exécutais Ant à partir d'Eclipse, mais les autres solutions mentionnées ici ne résolvaient pas mon problème. Ce qui est amusant, c’est qu’exécuter Ant à partir de la ligne de commande Windows fonctionnait bien. Il s’agissait donc d’un problème de configuration dans Eclipse.
Il s'est avéré que sous Eclipse, vous pouvez spécifier l'environnement avec lequel Ant devrait s'exécuter et ce dernier a été défini comme un JRE au lieu d'un JDK.
- Aller à: Exécuter -> Outils externes -> Configurations des outils externes ...
- Sélectionnez le fichier Ant build.xml pour votre projet (si vous avez plusieurs projets).
- Activer l'onglet 'JRE'
- Ici a été sélectionné 'Séparer JRE: jre6'. Lorsque j'ai changé cela en JDK de la série 1.6 ou 1.7, l'erreur avait disparu.
Vous avez utilisé une version supérieure du JDK pour compiler et essayer de fonctionner à partir d’une version inférieure du JDK / JRE .
Pour vérifier cela, voir les informations de version:
javac -version
Java -version
Ils seront différents et javac aura un numéro de version supérieur.
Pour résoudre ce problème, utilisez Java à partir de la version du kit JDK ou si vous utilisez un nouveau JRE/JDK qui fonctionnera également.
which javac vous indiquera l'emplacement, par exemple, /usr/bin/javac. Il suffit de lancer directement en utilisant /usr/bin/Java <program>.
OU vous pouvez définir la variable d'environnement comme solution permanente.
Je l'ai résolu. Iran:
Java_HOME=/usr/lib/jvm/Java-7-openjdk-i386
L'erreur est trompeuse, Unsupported major.minor version 51.0. Cela donne l'impression que la version 51 (Java 7) n'est pas prise en charge. Et nous devrions utiliser Java 6.
L'erreur aurait dû être:
La version actuelle de Java, 50, n'est pas prise en charge. Utilisez plutôt la version 7 de Java (51: 0 et plus).
Votre fichier Java est compilé avec une version différente (version supérieure du compilateur) de la version (version d'exécution inférieure) avec laquelle vous essayez de l'exécuter.
Il est entendu que les classes compilées avec des versions inférieures devraient être exécutées dans les dernières versions supérieures. Mais l’inverse (compilé avec une version supérieure du compilateur et essayer de l’exécuter avec une version d’exécution inférieure) est parfois tout à fait impossible.
Par conséquent, cette erreur s’affiche lorsque vous essayez d’exécuter votre programme. Version majeure.minor non prise en charge x.x
Q: J'ai créé une application en Java 7, mais lorsque mes utilisateurs tentent d'utiliser exécutez-le, ils obtiendront une erreur major.minor version 51.0 non supportée. Quoi est-ce que cela signifie et que puis-je faire à ce sujet?
A: Si vous compilez une application à l'aide de javac dans Java 7, les fichiers de classe résultants auront le numéro de version 51.0. Versions de Java avant 7 ne reconnaît pas ce numéro, vos utilisateurs auront donc passer à Java 7 avant d’exécuter votre application. Si tu n'es pas En utilisant n'importe quelle API Java 7, vous pouvez essayer de compiler votre application en utilisant javac -target 1.6 pour créer un fichier de classe compatible 1.6. Si ton l'application est déployée à l'aide de Webstart, vous pouvez spécifier le minimum version requise. Pour plus d'informations, voir la documentation sur Java Web Start et JNLP ici. Ce problème disparaîtra dès que nous aurons déclenché la mise à jour automatique sur. Java 7 pour les utilisateurs finaux ayant actuellement Java 6 sur leurs ordinateurs de bureau. Le la chronologie pour cela n’a pas encore été déterminée, nous voulons donner aux développeurs Il est temps de régler d’abord les problèmes entre leur code et JDK 7.
(Source: Oracle.com .)
J'avais eu ce problème lorsque je suis revenu à Java 6 et que j'ai essayé d'exécuter des classes précédemment compilées avec Java 7. Ce qui fonctionnait pour moi était Préférences> Java> Compilateur -> définir le niveau de conformité sur 1,6 et "configurer les paramètres du projet".
Aujourd'hui, ce message d'erreur est apparu dans notre Tomcat 7 sur Ubuntu 12.04.2 LTS (Precise Pangolin):
/var/log/Tomcat7/localhost.2014-04-08.log:
8 avr. 2014 09:00:55 org.Apache.catalina.core.StandardContext filterStart
SEVERE: exception de démarrage du filtre struts2
Java.lang.UnsupportedClassVersionError: controller/ReqAccept: major.minor version 51.0 non prise en charge (impossible de charger la classe controller.ReqAccept)
L'application Struts est compilée avec Java 7.
En fin de compte, quelqu'un a utilisé le "service Tomcat [arrêt/démarrage]" pour redémarrer Tomcat 7,
$ ps -ef | grep Java
Tomcat7 31783 1 32 20:13? 00:00:03/usr/lib/jvm/default-Java/bin/Java ...
$/usr/lib/jvm/default-Java/bin/Java -version
Version Java "1.6.0_27"
Ce qui provoque l'erreur "Unsupported major.minor version 51.0".
Lorsque nous avons utilisé "/etc/init.d/Tomcat7 [stop/start]" pour redémarrer Tomcat 7, le problème a été résolu.
$ ps -ef | grep Java
Tomcat7 31886 1 80 20:24? 00:00:10 /usr/local/Java/jdk1.7.0_15/bin/Java
$ /usr/local/Java/jdk1.7.0_15/bin/Java -version
Version Java "1.7.0_15"
Oh Mac OS X, j'ai pu résoudre ce problème en définissant la variable Java_HOME:
export Java_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_75.jdk/Contents/Home
Commençons d'abord par quelques notions de base ...
JRE est un composant de NetBeans / Eclipse / autonome qui vous fournira des bibliothèques, des plug-ins JVM, des plug-ins Java et un démarrage Web Java. Notez qu'il ne fournit pas de complieurs ou de débogueurs.
JDK est le sur-ensemble de JRE avec les compliers et les débogueurs.
Ainsi, lorsque vous aurez votre bibliothèque par défaut sous forme d’environnement JRE au lieu de JDK, vous pourrez importer des fichiers en temps utile, mais cela ne se compilera pas.
Au lieu de cela, définissez votre chemin sur JDK (j'utilise NetBeans et je les configure à l'aide de netbeans.conf dans netbeans/etc/netbeans.conf et modifie le chemin).
- Installez JDK 7.0.55 et définissez Java pour Eclipse pour JDK 7.0.55.
- Construisez le projet avec JDK 7.0.55 en configurant le chemin de génération JDK 7.0.55.
- Définissez le compilateur dans Eclipse pour JDK 7.0.55 dans le menu Windows -> Préférences -> Java -> Compiler - choisissez 1.7.
Dans mon cas, le problème était lié à la configuration de l'exécution du serveur:
Vérifiez que le JRE est la version dont vous avez besoin:
Le projet était en version 1.7 et le serveur JRE était défini sur 1.6. Après un passage à la version Java appropriée, le lancement a bien fonctionné.
J'ai eu le problème suivant: je devais exécuter une compilation Maven sur mon projet à partir de la ligne de commande afin d'exécuter mes tests unitaires. si j'ai apporté une modification à la classe de test et laissé Eclipse la recompiler automatiquement, l'erreur s'est produite, ainsi l'erreur "Unsupported major.minor version 51.0".
JDK6 et JDK7 sont installés, mais tous mes paramètres JRE pointaient en 1.6, à la fois dans le pom et depuis la page des propriétés du projet dans Eclipse. Aucune quantité de Maven Update Project et/ou d'actualisation n'a résolu ce problème.
Finalement, j'ai essayé de fermer le projet et de le rouvrir, et cela a semblé résoudre le problème! HTH
Vous avez compilé votre classe Java avec JDK 7 et vous essayez d’exécuter la même classe sur JDK 6.
La réponse est pour le problème:
Exception dans le fil "principal" Java.lang.UnsupportedClassVersionError: edu/stevens/cs549/dhts/main/LocalContext: Non pris en charge par la version majeure de major.minor 52.0
J'avais le même problème. Pour ceux qui rencontraient ce problème dans les instances AWS ec2 et qui étaient en quelque sorte redirigés ici vers cette question. Je réponds pour ceux-ci et aimerais partager ce que j'ai fait ..__ Je rencontrais des problèmes parce que les instances Amazon EC2 exécutaient Java version 1.7 et que mon projet n'était peut-être pas compatible avec ce logiciel, car j'utilisais Maven. type de préconfiguré pour Java 1.8 . J'ai donc installé la nouvelle version de Java:
Sudo yum -y install Java-1.8.0
Et puis l’important est de supprimer l’ancienne version:
Sudo yum remove Java-1.7.0-openjdk
N'oubliez pas de le supprimer après avoir installé la nouvelle version, sinon il utiliserait en permanence la même version plus ancienne et j'espère que cela résoudra votre problème, ce qui s'est déjà produit dans mon cas.
J'ai rencontré le même problème et je l'ai corrigé dans Linux .
Vérifiez votre $Java_HOME
Besoin de JDK 1.8 pour compiler/construire APK
Installez Java JDK 1.8 et modifiez le Java_HOME
Éditez ~/.bashrc et ajoutez votre chemin JDK 1.8 en tant que Java_HOME.
export Java_HOME=/usr/lib/jvm/Java-8-Oracle/jre/
Et source ~/.bashrc
Fermez la fenêtre/l’onglet actuel du terminal et exécutez $Java_HOME pour vérifier le chemin.
Depuis Java 9, -target est remplacé par --release.
Jusqu'à Java 11, les numéros disponibles pour --release sont 67, 8, 9, 10, 11.
Et vous pouvez deviner que les futures versions seront 12, 13 et ainsi de suite.
Pour compiler une jvm cible plus ancienne:
javac --release 7 Tmp.Java/ cela générera un fichier .class qui pourrait être exécuté sur jvm> = 7,
Ensuite, vous pouvez vérifier la version cible via:
javap -v Tmp | grep version
dans la sortie, major version identifie la version de jvm cible.
- 55 -> Java 11
- 54 -> Java 10
- 53 -> Java 9
- 52 -> Java 8
- 51 -> Java 7
- 50 -> Java 6
La version future supprimera d'autres versions plus anciennes:
- A partir de Java 11, les versions principales <= 49 _/(version Java <= 5), ne sont pas prises en charge.
- À partir de Java 12 et 13, les versions principales <= 50 (version Java <= 6), ne sont pas prises en charge.
Vous pouvez savoir quelles versions cibles sont prises en charge par javac actuel, via la commande suivante:javac -help | grep releases
Voici un autre moyen de résoudre ce problème sur Mac OS X avec Homebrew installed:
brew install Caskroom/cask/Java
J'ai eu la même situation, mais aucun des conseils ci-dessus n'a pas aidé :) Dans notre environnement, Tomcat fonctionnait en tant que service sous Windows. Nous avons installé Java 1.7 et configuré Java_HOME sur cette version. Bien sûr, les sources ont été construites sur Java 1.7. Néanmoins, le Tomcat a déclaré utiliser la version précédente de la machine virtuelle Java. Après une analyse approfondie, vérifiez que le service Tomcat installé sur Windows conserve l’ancienne valeur de Java_HOME pointant vers Java 1.6. Après avoir installé le nouveau service Tomcat, tout a été résolu . La conclusion est donc la suivante: lorsque vous modifiez la version Java et que Tomcat s'exécute en tant que service, vous devez réinstaller le service Tomcat.
J'ai eu le même problème avec Spring Source Tool (STS) IDE pour un Grails project. J'ai vérifié la version Java installée et la version Java du projet était 1.7. *. Plus tard, j'ai trouvé que dans le fichier GGTS.ini, la version Java était définie sur 1.6:
Solution:
-Dosgi.requiredJavaVersion = 1.6 remplacé par
- Dosgi.requiredJavaVersion = 1.7
Ajouter ci-dessous deux lignes avant -vmargs
- vm
jdk1.7.0_21/jre/lib/AMD64/server/libjvm.so
Problème résolu. Bonne codage.
- Cliquez sur Propriétés dans un projet.
- Accédez au chemin de construction Java.
- Cliquez sur Ajouter une bibliothèque.
- Cliquez sur Suivant dans la bibliothèque système JRE. Sélectionnez celui dont vous avez besoin s'il n'est pas sélectionné par défaut.
- Cliquez sur Terminer.
Vous avez terminé!
J'ai tout essayé. Réinstaller Tomcat est ce qui a finalement fonctionné. Voici ce que j'ai vérifié avant de le réinstaller.
Assurez-vous que vos variables environnementales ressemblent à ceci.
$ echo $Java_HOME
C:\Program Files\Java\jdk1.7.0_51\
$ echo $JRE_HOME
C:\Program Files\Java\jdk1.7.0_51\jre\bin
Assurez-vous qu'Eclipse utilise le même jre que vous avez défini Java_HOME (si Java_HOME n'est pas défini, il se basera sur JRE_HOME). Window > Prefrences > Java > Installed JREs (celui coché est celui par défaut)
Si vous apportez des modifications à l'un de vos fichiers Tomcat, notamment catalina.bat ou startup.bat, il est possible que vous demandiez à Tomcat d'utiliser une version de Java différente de celle que vous avez définie pour Java_HOME C:\Program Files (x86)\Apache\apache-Tomcat-7.0.26\bin.
assurez-vous de cocher les versions des variables d'environnement de Java, cela pourrait être simplement la différence entre les versions de Java_HOME (chemin JDK) et de JRE_HOME (chemin JRE), qui cause le problème
Pour moi, je recevais cette erreur sur la classe com/Sun/javadoc/Doclet. Après quelques recherches, j'ai constaté que j'avais accidentellement copié le tools.jar de Java 8 dans mon dossier Java 7.
Trouver le tools.jar pour Java 7 et le remettre dans le dossier a résolu mon problème. Donc, quelque chose à essayer.
Ajoutez ceci à votre fichier pom.xml:
<project ....>
<properties>
<maven.compiler.source>1.7</maven.compiler.source>
<maven.compiler.target>1.7</maven.compiler.target>
</properties>
</project>
Où 1.7 est la version de Java que vous avez l'intention d'utiliser. Ceci écrase le paramètre Maven du compilateur, il est donc bon de déboguer à partir d'ici.
J'ai résolu ce problème pour moi en vérifiant que les dépendances Maven étaient déployées dans l'Assemblée de déploiement. Dans mon cas, ils ne l'étaient pas.
L'ajouter a résolu le problème.
J'utilise OS X 10.11.5 (El Capitan) et j'ai essayé de définir Java_HOME et d'imposer la version "correcte" de Java via Maven. Rien n'a aidé.
Le problème est survenu lorsque le compte OS X a été déconnecté alors que l'application était toujours en cours d'exécution. Après s'être reconnecté, OS X a ouvert l'ancienne session de terminal avec un historique grisé. J'ai utilisé la même session de terminal pour construire le projet, mais j'ai échoué avec l'erreur de version de classe non prise en charge.
Nettoyer le projet Maven n'a pas aidé du tout.
Pour résoudre le problème, je devais simplement fermer la fenêtre du terminal à ouverture automatique et en utiliser une nouvelle.
Dans mon cas, le problème est dû à différentes versions de Java dans $ Java_HOME et $ PATH.
echo $Java_HOME
/usr/lib/jvm/Java-7-openjdk-AMD64/jre
echo $PATH
/opt/jdk/jdk1.8.0_151/bin:/usr/lib/jvm/Java-7-openjdk-AMD64/jre/bin:/usr/local/bin:/usr/bin:/bin
Une fois que je les ai mis à jour pour qu'ils prennent la même version de Java, le problème avait disparu.
export Java_HOME=/opt/jdk/jdk1.8.0_151
export PATH=$Java_HOME/bin:$PATH
Comme vous le savez, il est toujours bon d’avoir la variable d’environnement Java_home pour le répertoire bin de jdk (Java Development Kit).
en examinant votre problème ci-dessus, il semble que l'environnement d'exécution JRE recherche une classe incompatible avec la bibliothèque Superset de JDk. Je recommanderais d'avoir un package complet de JDK et JRE ou Jboss (si nécessaire) directement à partir de la source de téléchargement Oracle pour éviter de tels problèmes.
J'ai eu le même problème, et j'ai résolu ce problème par cette solution sur un Mac. J'espère que ça aide quelqu'un. C'est parce que le système ne connaît pas la version la plus récente de JDK et qu'il pointe toujours sur l'ancien JDK.
vous pouvez spécifier la "cible" du compilateur dans le fichier build.xml, si vous utilisez ant, comme ci-dessous:
<target name="compile" depends="init">
<javac executable="${Java_HOME}\bin\javac" srcdir="${src.dir}" target="1.6" destdir="${classes.dir}" debug="true"
deprecation="true" classpathref="compile.classpath" encoding="utf8">
<include name="**/*.Java" />
</javac>
</target>