Quando si esegue un'applicazione java o semplicemente "java", jvm ha esito negativo:

Si è verificato un errore durante l'inizializzazione di VM
java / lang / NoClassDefFoundError: java / lang / Object

Ecco un elenco di risposte errate :

1. La home directory Java corretta, inclusa la directory / bin, si trova sul PERCORSO globale

2. JAVA_HOME è impostato correttamente

3. L'esecuzione del comando java -fullversion funziona

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

4. I collegamenti simbolici in / usr / java puntano tutti alla corretta installazione di java

5. Non ho installato alcun java "predefinito" quando ho creato il sistema

6. java -version fallisce ... stesso errore di cui sopra

7. L'emissione dei comandi da sotto la struttura di directory dell'installazione java non funziona neanche

8. Questo è java a 64 bit per 64 bit

Qualche idea?

Questo problema deriva da un'installazione Java errata.

Possibilità 1

NOTA: questo scenario si applica solo a Java 8 e precedenti. A partire da Java 9, JRE è strutturato in modo diverso. rt.jar e gli amici non esistono più e Pack200 non viene più utilizzato.

La libreria standard di Java è contenuta in diversi barattoli, come ad esempio rt.jar, deploy.jar, jsse.jar, ecc Quando il JRE è confezionato, questi file JAR critici sono compressi con pack200 e memorizzati come rt.pack, deploy.pack, jsse.pack, ecc installatore Java dovrebbe decomprimerli. Se si verifica questo errore, a quanto pare non è successo.

È necessario eseguire manualmente unpack200su tutti i .packfile nelle cartelle lib/e nelle JRE lib/ext/.

finestre

Per decomprimere un .packfile (ad esempio rt.pack), eseguire:

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

Per decomprimere ricorsivamente tutti i .packfile, dall'esecuzione root di JRE:

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

* nix

Per decomprimere un .packfile (ad esempio rt.pack), eseguire:

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

Per decomprimere ricorsivamente tutti i .packfile, dall'esecuzione root di JRE:

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

Possibilità 2

Java ha installato male in qualche altro modo. Forse hai installato senza i diritti di amministratore o hai provato a estrarre semplicemente i file dal programma di installazione. Riprova con il programma di installazione e / o altri privilegi. Oppure, se non si desidera utilizzare il programma di installazione, utilizzare .tar.gzinvece il pacchetto Java.

Per Java 8 su un sistema operativo * nix, vai a <jdk root>/jre/lib(per me, /usr/java/jdk1.8.0_05/jre/lib). Da questa directory, eseguire:

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

Per evitare problemi di versione nel caso in cui sia installato un altro JRE, utilizzare lo stesso unpack200fornito con il JRE che si sta risolvendo, ovvero dalla riga di comando, utilizzare ../../bin/unpack200(per me, questo si espande in /usr/java/jdk1.8.0_05/bin/unpack200), non solo unpack200.

Sembra che per un'architettura a 64 bit sia necessario installare sia la versione a 32 bit che la versione a 64 bit di jre (i file indipendenti dall'architettura come rt.jar sono distribuiti solo nella versione a 32 bit).

Ricorda quindi di prestare attenzione a includere l'eseguibile java corretto nella variabile d'ambiente PATH globale.

Soluzione rapida per persone impazienti;) Su macchine Windows , prova questo: vai alla C:\Windows\System32directory ed elimina java.exe(o rinomina in qualcosa del genere java.exe.old).

Da almeno 1.6, non ci dovrebbe essere un java.exenella directory di Windows. Se c'è, è un residuo di qualcosa.

Un po 'più di lettura:

Sono davvero sorpreso che una domanda del 2012 non abbia ancora una risposta approvata e ho effettivamente riscontrato lo stesso problema nel 2015 sul mio sistema operativo Windows 7 a 32 bit!

Quindi cosa è successo?

Fondamentalmente, tutto funzionava bene, ho scaricato il database H2 e quando ho cercato di iniziare H2 Console (Command Line)ho ottenuto:

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

Ho trovato questa domanda e sono stato in grado di confermare gli stessi sintomi:

JAVA_HOME è impostato correttamente:

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

java -versionfallisce, mentre java --fullversionfunziona benissimo:

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

SOLUZIONE: vai alla C:\Windows\System32directory ed elimina il file (in realtà ho rinominato) java.exe!!!!

Ora ricevo:

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)

e H2 Console (Command Line)funziona anche bene!

I crediti vanno all'ultimo messaggio in questo forum: https://bukkit.org/threads/java-lang-noclassdeffounderror-java-lang-object.70450/

Ho scaricato il nuovo JDK oggi (1.8.0.73) iniziato c:> java.exee ho ottenuto il famigerato:

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

Volevo solo condividere la mia soluzione di lavoro qui.

Quando ho inserito il cd nella jdk\bincartella, Java funzionava bene, quindi sapevo che era il PATH. Ho deciso PATHdi \jdk\bindimostrarlo e ha funzionato.

Quindi, ho pensato che una delle cartelle del PATHmust have java.execausasse il conflitto. Come si è scoperto, era C:\>ProgramData\Oracle\Java\javapathche contiene collegamenti simbolici agli eseguibili.

java.exestava indicando jre\bin. Il file era corrotto, quando ho iniziato: \jre\bin\java.exelo stesso errore esatto. Bingo. Ho reinstallato JRE e il problema è scomparso. Buona codifica ...

Molto probabilmente ti manca un file chiamato rt.jar nella tua installazione che ha il file di classe per java.lang.Object. Controlla i tuoi file di installazione ecc.

In particolare, si noti che un overtsaller a 64 bit si sovrappone (o installa "accanto a") un'installazione esistente a 32 bit. In altre parole, per ottenere un'installazione a 64 bit completamente funzionante, devi prima eseguire l'installazione a 32 bit e seguirla con un'installazione a 64 bit se hai una macchina a 64 bit ...

Se invece esegui solo un'installazione a 64 bit ti mancheranno alcuni file nell'installazione e otterrai errori come quello sopra.

Su Windows 10, ho riscontrato lo stesso problema con JRE 1.8 (8u121).
Digitando

java -version

il prompt cmd ritorna

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

Tutti gli altri comandi, echo %JAVA_HOME%, echo %JRE_HOME%, echo %PATH%, java -fullversionha funzionato bene.

Accedere alle variabili di ambiente sul pannello di amministrazione del sistema, rimuovere da PATH il collegamento C:\ProgramData\Oracle\Java\javapathe assicurarsi di aver impostato in PATH il collegamento C:\Program Files\Java Folder\bin.

Successivamente, controlla se C:\Windows\System32esiste un java.exefile; se vero, elimina quel file.

Digitando ora java -versionfunziona benissimo.

Questo problema si verifica quando si installa JDK da _uncompressing_esso anziché da _executing_esso.

Per esempio:

unzip jdk-6u45-linux-x64.bin  (wrong)

sh ./jdk-6u45-linux-x64.bin   (right)

Nel primo scenario, le librerie di runtime, come rt.jar, non vengono automaticamente decompresse (quindi, puoi trovare i file rt.pack, ecc. Invece di quelli .jar).

Ho avuto lo stesso problema di recente. Nel mio caso la mia macchina Windows 7 ha scaricato automaticamente java e aggiunto C:\ProgramData\Oracle\Java\javapathall'inizio della mia variabile d'ambiente path, che ha incasinato la mia java. Una volta che me ne sono liberato dal percorso, ha funzionato.

se fai "chmod u + rx" sul binario java ed eseguilo, decomprimerà i file jar e potrai fare una versione java senza errori di runtime

Non è possibile installare solo 64 bit, è necessario prima installare 32 bit e quindi aggiungere i componenti a 64 bit.

Da java.com:

L'installazione di JRE su un sistema a 64 bit che consente una JVM a 32 bit è un processo in due passaggi: installare prima JRE a 32 bit e quindi installare il supporto aggiuntivo per le operazioni a 64 bit. I nomi dei file sono i seguenti:

Se si installa una versione a 64 bit senza prima installare 32 bit, questo errore si verificherà nonostante la risoluzione di tutti gli altri problemi. Ho un nuovissimo Dell i7 64-bit Windows 10 Pro con Java 8u71. Dopo aver aggiunto il mio% path% e% classpath% alle variabili di ambiente e aver provato diverse altre correzioni, disinstallando 64 bit, installando 32 bit e reinstallando 64 bit è stato risolto.

Alcuni dei problemi, come la mancata decompressione dei file, ecc., Che sono stati menzionati come possibili cause, potrebbero ancora causare problemi, ma se non lo fai, anche le altre correzioni non funzioneranno.

Nel mio caso, utilizzo Windows 8.1 (installato jdk1.8.0_77), ho fatto tre cose:

1. Ho cancellato jdks precedenti
2. Ho rinominato il file java.exe all'interno di C: \ Windows \ System32
3. Ho anche rimosso C: \ ProgramData \ Oracle \ Java \ javapath nel mio PATH (echo% PATH%)

e voilà l'ha risolto!

Ho affrontato il problema simile e ho scoperto che il collegamento simbolico nei dati del programma (C: \ ProgramData \ Oracle \ Java \ javapath) era errato. Ho dato il percorso corretto e ha funzionato.

I dettagli su come correggere i dati del programma sono disponibili qui

Un'altra risposta potrebbe essere quella di utilizzare il file tar.gz invece nel caso Linux. Sembra che ci sia qualcosa di simile anche per la piattaforma Solaris. In questo modo tutti i file saranno già nel formato previsto e non ci saranno problemi di decompressione.

Ho qualche problema con le installazioni Linux x86_64 con JDK 1.7.0_40 i586. Ho capito che il problema è che rpm non è in grado di decomprimere i file jar, come menzionato da Rigg802 (anche se rpm completa il successo):

Unpacking JAR files...
        rt.jar...
/var/tmp/rpm-tmp.zLzkkb: /usr/java/jdk1.7.0_40/bin/unpack200: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory
Error: unpack could not create JAR file:

        /usr/java/jdk1.7.0_40/jre/lib/rt.jar

Il file /lib/ld-linux.so.2 è fornito da glibc-2.12-1.107.el6_4.4. i686 che non è tra i giri / min di jdk rpm.

Oracle JDK rpm richiede anche versioni a 32 bit di libgcc-4.4.7-3.el6. i686 da installare

Quindi, la soluzione alternativa è installare prima glibc-2.12-1.107.el6_4.4.i686 e libgcc-4.4.7-3.el6.i686.

Soluzione rapida che ha funzionato per me:

for file in $(find "$JAVA_HOME" -name "*pack")
do 
    unpack200 "${file}" "${test_file/%pack/jar}";
done

Ho scoperto che questo errore si è verificato quando ho estratto il file .rpm.

Ho quindi rimosso quella cartella e scaricato jdk-7u79-linux-x64.tar.gz per Linux 64 e invece ho estratto il contenuto di questo file. Inoltre: export JAVA_HOME = / opt / java / jdk1.7.0_79 export JDK_HOME = / opt / java / jdk1.7.0_79 export PATH = $ {JAVA_HOME} / bin

Installa di nuovo jre . Ha semplicemente risolto il mio problema. (Il batch di avvio SonarQube ha iniziato a dare questo errore dopo aver installato jdk)

Vai al pannello di controllo, disinstalla le informazioni relative a Java (chiudi Eclipse se aperto), quindi reinstalla Java e apri Eclipse, progetti puliti.

Ho appena fatto questo su Solaris e ho riscontrato questo identico problema in cui anche "java -version" non funziona. C'è una ragione per cui le versioni a 64 bit della distribuzione sono MODO più piccole di quelle a 32 bit. È infatti come sopra indicato:

In altre parole, per ottenere un'installazione a 64 bit completamente funzionante, devi prima eseguire l'installazione a 32 bit e seguirla con un'installazione a 64 bit se hai una macchina a 64 bit ...

Quindi ho eseguito il programma di installazione per il 32 bit:

sh jdk-6u131-solaris-sparc.sh

Quindi ho eseguito il programma di installazione per 64-bit:

sh jdk-6u131-solaris-sparcv9.sh

Questo mi dà diversi eseguibili Java tra cui scegliere:

• $ find. -name java
• ./jdk1.6.0_131/db/demo/programs/scores/java
• ./jdk1.6.0_131/db/demo/programs/vtis/java
• ./jdk1.6.0_131/bin/java
• ./jdk1.6.0_131/bin/sparcv9/java
• ./jdk1.6.0_131/jre/bin/java
• ./jdk1.6.0_131/jre/bin/sparcv9/java

Gli sparcv9 java sono le versioni a 64 bit e funzionano con "-version" se installati insieme al JDK a 32 bit.

• ./jdk1.6.0_131/bin/sparcv9/java -version
• versione java "1.6.0_131"
• Java (TM) SE Runtime Environment (build 1.6.0_131-b32)
• VM per server a 64 bit Java HotSpot (TM) (build 20.131-b32, modalità mista)

-Dan

Nella finestra 10 è già presente un percorso in env poiché C:\>ProgramData\Oracle\Java\javapathcontiene collegamenti simbolici agli eseguibili.

Quando installo una nuova versione e la rimuovo dalla mia variabile d'ambiente, tutto il mio progetto inizia a mostrarla.

Sto usando l'ossigeno dell'eclissi nella finestra 10

Per risolverlo: -

1. Ho appena rimosso il percorso C:\>ProgramData\Oracle\Java\javapathdalla variabile d'ambiente e ho aggiunto un nuovo env come JAVA_HOME e% JAVA_HOME% / bin nel percorso

2. Reinstallo jdk con i privilegi di amministratore (elimino la cartella JRE precedente)

3. Apri il tuo progetto eclissi> tasto destro> Vai a Proprietà> Nelle librerie> Ora rimuovi libreria di sistema JRE> Fai clic su Aggiungi libreria> seleziona "Libreria di sistema JRE"> Fai clic su Avanti> Seleziona "JRE predefinito dell'area di lavoro (jre1.8.x_xxx)"> finire

Il mio problema è stato risolto :) Spero che ti possa aiutare :)

Questo risolto il problema che avevo su CentOS

sudo yum install java-1.8.0-openjdk-devel

vedi anche l' impostazione di JAVA_HOME & CLASSPATH in CentOS 6

Quindi, ho continuato a provare tutto e alla fine sembra che reinstallare Java dopo averlo disinstallato abbia risolto il mio problema.

in caso di problemi con la versione di installazione di JAVA

C: \ Where JAVA

darà la posizione di java che raccoglie. Se hai un percorso diverso dalla tua installazione, rimuovi quei file o rinominali (potrebbe essere come _backup). otterrai la versione corretta del file java.

Ho riscontrato lo stesso problema, ho installato due versioni Java quindi ha causato questo problema. per confermare vai e fai clic sull'icona java nel pannello di controllo se non si apre, quindi il problema è lo stesso, vai e disinstalla una versione. pezzo di torta. Grazie.

Stavo affrontando lo stesso problema: si è verificato un errore durante l'inizializzazione di VM java / lang / NoClassDefFoundError: java / lang / Object

Seguire i passaggi seguenti per risolvere il problema:

Passaggio 1. Andare a C: \ Programmi \ e cercare la cartella Java.

Passaggio 2. Eliminare la cartella C: \ Programmi \ Java.

Passaggio 3. Scarica il nuovo Jdk per la tua versione a 32 bit / 64 bit da http://www.oracle.com/technetwork/java/javase/downloads/index.html

Passaggio 4. Installa JDK

Passaggio 5: ora imposta JAVA_HOME su "C: \ Programmi \ Java \ jdk1.8.0_91"

Passaggio 6: apri il prompt dei comandi e inserisci java -version.

Funziona.