Class File Version zu niedrig? Ausführen über Eingabeaufforderung nicht möglich

[dapzoo]

Hallo,

das Konvertieren zur .class Datei via javac dateiname.java funktioniert soweit. Jedoch erscheint eine Fehlermeldung, wenn ich die .class Datei via java dateiname ausführen will:

java.lang.UnsupportedClassVersionError: VerdienstJob has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 54.0

Ich hab bereits versucht die Compliance-Stufe in Eclipse eine Stufe niedriger zu stellen, sodass es mit meiner installierten JRE 10.0.2 kompatibel sein müsste(?), vergeblich. Was mach ich da? Java SE DK10, statt 11, zu installieren scheint mir irgendwie auch nicht das Richtige zu sein.

 

[httpdigest]

Naja, du scheinst offensichtlich ein 10er JRE zu haben und zu versuchen, deine Klasse mit diesem JRE (bzw. dem darin enthaltenen java Executable) zu starten. Was wird denn ausgegeben, wenn du statt `java DeineHauptklasse` `java -version` ausführst?

Ich hab bereits versucht die Compliance-Stufe in Eclipse eine Stufe niedriger zu stellen, sodass es mit meiner installierten JRE 10.0.2 kompatibel sein müsste(?), vergeblich.

Ist VerdienstJob auch eine Klasse, die du selber aus Java-Sourcen heraus kompilierst, oder kommt es eventuell aus einer bereits kompilierten Klasse innerhalb einer Jar-Datei?
Und hast du in den Eclipse Compiler Einstellungen auch wirklich "Generated .class files compatibility:" auf "10" gesetzt?

 

[dapzoo]

Naja, du scheinst offensichtlich ein 10er JRE zu haben und zu versuchen, deine Klasse mit diesem JRE (bzw. dem darin enthaltenen java Executable) zu starten. Was wird denn ausgegeben, wenn du statt `java DeineHauptklasse` `java -version` ausführst?

Ist VerdienstJob auch eine Klasse, die du selber aus Java-Sourcen heraus kompilierst, oder kommt es eventuell aus einer bereits kompilierten Klasse innerhalb einer Jar-Datei?
Und hast du in den Eclipse Compiler Einstellungen auch wirklich "Generated .class files compatibility:" auf "10" gesetzt?

Das hier:
java version "10.0.2" 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

 

[httpdigest]

Das beantwortet leider nur ein Drittel der Fragen, die du auch von mir gequotet hast.

 

[dapzoo]

Ähm, huch.

Ist VerdienstJob auch eine Klasse, die du selber aus Java-Sourcen heraus kompilierst, oder kommt es eventuell aus einer bereits kompilierten Klasse innerhalb einer Jar-Datei?
Und hast du in den Eclipse Compiler Einstellungen auch wirklich "Generated .class files compatibility:" auf "10" gesetzt?

Ich hab ganz normal über Eclipse ein neues Projekt erstellt, darin diese Klasse geschrieben und gespeichert. (Wobei ich nicht weiß ob das die Frage beantwortet, ich bin noch völliger Neuling. 😀)

Zu der anderen Frage, hier sind meine Einstellungen. Ich hab es einmal mit Stufe 9 und einmal mit 10 probiert. Bei beiden die gleiche Fehlermeldung.

 

[httpdigest]

Und du bist auch sicher, dass du die Klasse startest, die durch Eclipse gebaut wurde? Wenn du mal die Java-Klasse ein bisschen anpasst, speicherst, und dann auf das Dateiänderungsdatum (im Dateimanager deiner Wahl - in den Dateieigenschaften) schaust, kommt das auch hin? Lösche die .class Datei auch einfach mal und klicke in Eclipse auf Menü "Project" -> "Clean..." (mit OK bestätigen). Erscheint die .class Datei dann wieder?
Weil, das Ganze passt irgendwie nicht zusammen gerade.

 

[mrBrown]

BTW: 10 hat „end of Support“ erreicht, warum nutzt du nicht das aktuelle 11er als JRE? 😉

 

[dapzoo]

Und du bist auch sicher, dass du die Klasse startest, die durch Eclipse gebaut wurde? Wenn du mal die Java-Klasse ein bisschen anpasst, speicherst, und dann auf das Dateiänderungsdatum (im Dateimanager deiner Wahl - in den Dateieigenschaften) schaust, kommt das auch hin? Lösche die .class Datei auch einfach mal und klicke in Eclipse auf Menü "Project" -> "Clean..." (mit OK bestätigen). Erscheint die .class Datei dann wieder?
Weil, das Ganze passt irgendwie nicht zusammen gerade.

Ja, da bin ich mir sicher. Ich habs ja auch bereits mit verschiedenen, neu erstellten Klassen versucht. Es muss ja dann die Klasse sein, die durch Eclipse gebaut wurde, wenn die Klasse vorher gar nicht existent war, oder? Oder überseh ich jetzt was

BTW: 10 hat „end of Support“ erreicht, warum nutzt du nicht das aktuelle 11er als JRE? 😉

Gibt es denn eine 11er JRE Version?

 

[httpdigest]

Es muss ja dann die Klasse sein, die durch Eclipse gebaut wurde, wenn die Klasse vorher gar nicht existent war, oder?

Meine Vermutung war hier, dass du eventuell auch in den Build Path Einstellungen vom Projekt eventuell das Output Directory angepasst hast, aber immer noch die .class Dateien im "alten" Verzeichnis versuchst du starten.

 

[mrBrown]

Gibt es denn eine 11er JRE Version?

Ja. Entweder das normale JDK (was du ja anscheinend installiert hast) nutzen oder explizit ein JRE aussuchen: https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/latest

 

[dapzoo]

Ja. Entweder das normale JDK (was du ja anscheinend installiert hast) nutzen oder explizit ein JRE aussuchen: https://github.com/AdoptOpenJDK/openjdk11-binaries/releases/latest

Ich hab nun die JRE deinstalliert, das JDK (aktuellste Version) neu installiert und es nochmals probiert. Obwohl ich bei den Systemumgebungsvariablen bei Path den Pfad zum JDK bin Ordner gespeichert habe, kommt nun folgende Meldung:

C:\Users\User\eclipse-workspace\Tutorial\src\Typumwandlung>java VerdienstJob
Error: opening registry key 'Software\JavaSoft\JRE'
Error: could not find java.dll
Error: Could not find Java SE Runtime Environment.

Mir ist diesmal auch aufgefallen, dass bei JDK eine "private JRE" mit installiert wird. Aber es scheint nicht gefunden zu werden...

Edit: Wieder alles deinstalliert, Systemvariable von Java Pfaden entfernt, OpenJDK 11 installiert und dem hier gefolgt:

1. Set a PATH:
   • Select Control Panel and then System.
   • Click Advanced and then Environment Variables.
   • Add the location of the bin folder of the JDK installation to the PATH variable in System Variables.
   • The following is a typical value for the PATH variable: C:\WINDOWS\system32;C:\WINDOWS;"C:\Program Files\Java\jdk-11\bin"
2. Set JAVA_HOME:
   • Under System Variables, click New.
   • Enter the variable name as JAVA_HOME.
   • Enter the variable value as the installation path of the JDK (without the bin sub-folder).
   • Click OK.
   • Click Apply Changes.

Jetzt wird mir via java -version alles korrekt angezeigt.

Allerdings tritt nun ein neuer Fehler auf, wenn ich die .class Datei ausführen will (aus der CMD kopiert):


C:\Users\user\eclipse-workspace\Tutorial\src\Typumwandlung>javac VerdienstJob.java

C:\Users\user\eclipse-workspace\Tutorial\src\Typumwandlung>java VerdienstJob
Error: Could not find or load main class VerdienstJob
Caused by: java.lang.NoClassDefFoundError: Typumwandlung/VerdienstJob (wrong name: VerdienstJob)

Das Übersetzen in eine class Datei hat er noch geschafft. Das Ausführen selbiger plötzlich nicht mehr.

 

[dapzoo]

Klappt nun plötzlich. Woran es genau lag, kann ich nicht sagen. Ich hab das Compliance Level mehrmals verstellt, alle alten Projekte gelöscht, ein neues erstellt, den Build Path nochmals gecheckt,... ja, klappt nun auf jeden Fall endlich. 🙂

 

[Neumi5694]

Ich arbeite mit Netbeans, weiß also nicht, wofür der Compilence Level gedacht ist, in Netbeans wähl ich die JDK aus, mit der kompiliert werden soll.
Prinzipiell gilt: Kompiliere mit der JDK, die du als Mindest-JRE-Version voraussetzt. Und dann stell natürlich auch sicher, dass das Ziel-System mit der JRE arbeitet.

 

[mihe7]

Das Compliance Level dürfte nichts anderes als die Angabe sein, welcher Java-Version der Quellcode entspricht (-source-Switch von javac)

Hat man z. B. Code, der "assert" als Bezeichner verwendet, wäre das seit Java 1.4 ein Fehler.
Beispiel:

public class Test {
    public static void assert(boolean x) {}
}

Übersetzung:

~$ javac Test.java
Test.java:6: error: as of release 1.4, 'assert' is a keyword, and may not be used as an identifier
    public static void assert(boolean v) {
                       ^
  (use -source 1.3 or lower to use 'assert' as an identifier)
1 error

# dagegen
~$ javac -source 1.3 Test.java
warning: [options] bootstrap class path not set in conjunction with -source 1.3
warning: [options] source value 1.3 is obsolete and will be removed in a future release
warning: [options] target value 1.4 is obsolete and will be removed in a future release
warning: [options] To suppress warnings about obsolete options, use -Xlint:-options.
Test.java:6: warning: as of release 1.4, 'assert' is a keyword, and may not be used as an identifier
    public static void assert(boolean v) {
                       ^
  (use -source 1.4 or higher to use 'assert' as a keyword)
5 warnings

Das produziert hier ein 1.4er-class-File:

~$ file Test.class
Test.class: compiled Java class data, version 48.0 (Java 1.4)

Nimmt man noch den target-Switch hinzu (javac -source 1.3 -target 1.8 Test.java), erhält man

~$ file Test.class
Test.class: compiled Java class data, version 52.0

Wann braucht man das? So gut wie nie.

 

[Neumi5694]

Das Compliance Level dürfte nichts anderes als die Angabe sein, welcher Java-Version der Quellcode entspricht (-source-Switch von javac)

Hab ich so ähnlich vermutet, wollte ich aber nicht ohne Überprüfung annehmen. In Netbeans wäre das dann die Eigenschaft "Source/Binary Format".