JRE 1.7 - version de java - renvoie : java/lang/NoClassDefFoundError : java/lang/Object

Question

Lors de l'exécution de n'importe quelle application java, ou simplement de 'java', la jvm échoue :

Une erreur s'est produite pendant l'initialisation de la VM
java/lang/NoClassDefFoundError : java/lang/Object

Voici une liste de mauvais réponses :

1. Le répertoire d'accueil Java correct, y compris le répertoire /bin, se trouve dans le PATH global.

2. JAVA_HOME est correctement défini

3. L'exécution de la commande java -fullversion fonctionne

   $ java -fullversion
   
   ./java full version "1.7.0_05-b05"

4. Les liens symboliques dans /usr/java pointent tous vers l'installation correcte de Java.

5. Je n'ai pas installé de Java par défaut lorsque j'ai créé le système.

6. java -version échoue... même erreur que ci-dessus

7. L'exécution des commandes à partir de la structure de répertoire de l'installation java ne fonctionne pas non plus.

8. C'est du java 64 bits pour un ordinateur 64 bits.

Des idées ?

Answer 1

Ce problème provient d'une mauvaise installation de Java.

Possibilité 1

NOTE : Ce scénario ne s'applique qu'à Java 8 et aux versions antérieures. À partir de Java 9, le JRE est structuré différemment. rt.jar et ses amis n'existent plus, et Pack200 n'est plus utilisé.

La bibliothèque standard de Java est contenue dans divers JAR, tels que rt.jar , deploy.jar , jsse.jar etc. Lorsque le JRE est empaqueté, ces fichiers JAR critiques sont comprimés avec Pack200 et stocké comme rt.pack , deploy.pack , jsse.pack etc. Le programme d'installation de Java est censé les décompresser. Si vous rencontrez cette erreur, cela ne s'est apparemment pas produit.

Vous devez exécuter manuellement unpack200 sur tous les .pack dans le fichier lib/ y lib/ext/ les dossiers.

Windows

Pour déballer un .pack (par exemple rt.pack ), courez :

"%JAVA_HOME%\bin\unpack200" -r -v rt.pack rt.jar

Pour déballer récursivement tous les .pack à partir de l'exécution de la racine de JRE :

for /r %f in (*.pack) do "%JAVA_HOME%\bin\unpack200.exe" -r -q "%f" "%~pf%~nf.jar"

*nix

Pour déballer un .pack (par exemple rt.pack ), courez :

/usr/bin/unpack200 -r -v rt.pack rt.jar

Pour déballer récursivement tous les .pack à partir de l'exécution de la racine de JRE :

find -iname "*.pack" -exec sh -c "/usr/bin/unpack200 -r -q {} \$(echo {} | sed 's/\(.*\.\)pack/\1jar/')" \;

Possibilité 2

Vous avez mal installé Java d'une autre manière. Vous avez peut-être installé sans droits d'administrateur ou essayé d'extraire simplement les fichiers du programme d'installation. Essayez à nouveau avec le programme d'installation et/ou avec plus de privilèges. Ou, si vous ne voulez pas utiliser le programme d'installation, utilisez la commande .tar.gz paquet Java à la place.

Answer 2

Pour Java 8 sur un système d'exploitation *nix, rendez-vous à l'adresse suivante <jdk root>/jre/lib (pour moi, /usr/java/jdk1.8.0_05/jre/lib ). À partir de ce répertoire, exécutez :

../../bin/unpack200 rt.pack rt.jar
../../bin/unpack200 jsse.pack jsse.rar
../../bin/unpack200 charsets.pack charsets.jar

Pour éviter les problèmes de version au cas où vous auriez installé un autre JRE, utilisez le même fichier unpack200 qui est livré avec le JRE que vous corrigez - c'est-à-dire, à partir de la ligne de commande, utilisez ../../bin/unpack200 (pour moi, cela s'étend à /usr/java/jdk1.8.0_05/bin/unpack200 ), et pas seulement unpack200 .

Answer 3

Il semble que pour une architecture 64 bits, vous devez installer à la fois la version 32 bits et la version 64 bits de jre (les fichiers indépendants de l'architecture comme rt.jar ne sont distribués que dans la version 32 bits).

N'oubliez donc pas de faire attention à inclure le bon exécutable java dans la variable d'environnement PATH globale.

Answer 4

Solution rapide pour les personnes impatientes ;) Sur Windows machines, essayez ceci : Allez sur C:\Windows\System32 et supprimer java.exe (ou le renommer en quelque chose comme java.exe.old ).

Depuis au moins la 1.6, il ne devrait pas y avoir de java.exe dans le répertoire Windows. Si c'est le cas, c'est un reste de quelque chose.

Un peu plus de lecture :

Je suis vraiment surpris qu'une question de 2012 n'ait pas encore de réponse approuvée et j'ai effectivement rencontré le même problème en 2015 sur mon OS Win 7 32-Bit !

Alors que s'est-il passé ?

En gros, tout fonctionnait bien, j'ai téléchargé la base de données H2 et quand j'ai essayé de démarrer H2 Console (Command Line) J'ai eu :

Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

J'ai trouvé cette question et j'ai pu confirmer les mêmes symptômes :

JAVA_HOME est correctement défini :

echo %JAVA_HOME%
C:\Program Files\Java\jdk1.6.0_26

java -version échoue, tandis que java --fullversion fonctionne bien :

java -fullversion
java full version "1.6.0_45-b06"

SOLUTION : Aller à C:\Windows\System32 et supprimer (j'ai en fait renommé) java.exe fichier !!!!

Maintenant, je comprends :

java -version
java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)

y H2 Console (Command Line) fonctionne également très bien !

Les crédits vont au dernier message dans ce forum : https://bukkit.org/threads/java-lang-noclassdeffounderror-java-lang-object.70450/

Answer 5

J'ai téléchargé le nouveau JDK aujourd'hui (1.8.0.73) et j'ai démarré. c:> java.exe et a obtenu l'infâme :

Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object

Je voulais juste partager ma solution de travail ici.

Quand je suis entré dans le jdk\bin Java s'exécutait bien, donc je savais que c'était le dossier PATH . J'ai mis PATH à juste \jdk\bin au CMD pour le prouver et ça a marché.

Donc, l'un des dossiers dans le PATH a dû avoir java.exe qui causait le conflit, je pensais. Il s'est avéré que c'était C:\>ProgramData\Oracle\Java\javapath qui détient liens symétriques aux exécutables.

java.exe indiquait jre\bin . Le fichier était corrompu, quand j'ai commencé \jre\bin\java.exe --...exactement la même erreur. Bingo. J'ai réinstallé JRE et le problème a disparu. Bon codage...