Java UnsupportedClassVersionError (51), aber nur beim Ausführen von Befehl von Remote-Maschine

Question

Ich habe eine einfache TestNG-Setup, wo ich eine Hauptklasse von der Befehlszeile aufrufen. Der Test läuft perfekt.

Ich führe sie über die Befehlszeile, weil ich die Ausführung von HP Quality Center auslösen muss. Dies funktioniert auch, solange der QC-Client, der die Befehlszeile auslöst, am gleichen Ort wie die kompilierten Testklassen läuft.

Wenn ich jedoch versuche, die Befehlszeile von einem Remote-Host auszulösen, erhalte ich einen kleineren 51 Hauptfehler. Ich weiß, dass dies bedeutet, dass die Klassen mit Java 1.7 kompiliert wurden und versuchen, mit einer niedrigeren Java-Ebene zu laufen. Was ich nicht verstehe ist, wie und warum es eine niedrigere Version von Java verwendet. Eine Befehlszeile java -version zeigt, dass auf der ausführenden VM ein Java 1.8_91 ausgeführt wird. Früher hatte es ein 1.6_19, aber ich habe es aktualisiert. Ich habe auch Systemvariablen für Pfad und JAVA_HOME geändert und andere Systemvariablen durchgesehen, ohne etwas zu finden, das auffällt.

Wie ist es möglich, dass die Befehlszeile zwei verschiedene Versionen von Laufzeit-Java auslöst, wenn sie vom lokalen und Remote-Host ausgeführt werden? Wie kann ich das beheben, so dass sie in beiden Fällen 1,8 verwenden?

PS, ist die kompilierten Klassen auf 1,6 Herabstufung keine Option, wie TestNG uopn 1.7

hier depentend wird die Ausnahme ausgelöst:

Error Number: 8 
Source: executeCommand 
Description: java.lang.UnsupportedClassVersionError: org/testng/TestNG : Unsupported major.minor version 51.0 
    at java.lang.ClassLoader.defineClass1(Native Method) 
    at java.lang.ClassLoader.defineClassCond(Unknown Source) 
    at java.lang.ClassLoader.defineClass(Unknown Source) 
    at java.security.SecureClassLoader.defineClass(Unknown Source) 
    at java.net.URLClassLoader.defineClass(Unknown Source) 
    at java.net.URLClassLoader.access$000(Unknown Source) 
    at java.net.URLClassLoader$1.run(Unknown Source) 
    at java.security.AccessController.doPrivileged(Native Method) 
    at java.net.URLClassLoader.findClass(Unknown Source) 
    at java.lang.ClassLoader.loadClass(Unknown Source) 
    at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) 
    at java.lang.ClassLoader.loadClass(Unknown Source) 
Could not find the main class: org.testng.TestNG. Program will exit. 
Exception in thread "main" While executing command: java -cp c:\test\Execution\lib\*;c:\test\Execution\bin org.testng.TestNG c:\test\Execution\testng.xml 

und der Befehl selbst:

C:\Users\myUser>java -cp C:\test\Execution\lib\*;C:\test\Execution\bin org.testng.TestNG C:\test\Execution\testng.xml 

lib enthält einige JAR-Dateien, wie Selenium und TestNG. Die Datei testng.xml kann Konfigurationen für genau die Tests enthalten, die innerhalb einer Klasse ausgeführt werden, ist in diesem Fall jedoch leer. Der bin-Ordner enthält den kompilierten Java-Testfall selbst und einige Datendateien, die für Parameter verwendet werden.

UPDATE: ich natürlich sollte eine einfache java -version ausgeführt haben, von Anfang an, aber jetzt habe ich, und hier sind die Ergebnisse:

Wenn von Kommandozeilen laufen direkt innerhalb VM:

java version "1.8.0_91" 
Java(TM) SE Runtime Environment (build 1.8.0_91-b14) 
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode) 

wenn von Quality Center Script ausgeführt wird, von Browser innerhalb der VM (hier muß ich die aktuelle Ausgabe in einer Datei speichern, um zu sehen, und das scheint nur, wenn java -verbose -version mit zu arbeiten):

[Opened D:\java\JDK 1.8.0_91\lib\rt.jar] 
[Loaded java.lang.Object from D:\java\JDK 1.8.0_91\lib\rt.jar] 
[Loaded java.io.Serializable from D:\java\JDK 1.8.0_91\lib\rt.jar] 
... etc 

Wenn von Quality Center Script ausgeführt wird, von Browser außerhalb der VM (auch java -verbose -version):

[Loaded java.lang.Object from shared objects file] 
[Loaded java.io.Serializable from shared objects file] 
[Loaded java.lang.Comparable from shared objects file] 
.... 
[Opened C:\Program Files (x86)\Java\jre6\lib\rt.jar] 
.... 

Nach den oben genannten Java-Ordnern löschen und alle damit zufrieden ist, waren die Ausgabe des Befehls vollständig leer , in meiner Textdatei.

diese Frage, what is shared objects file?, gibt mir einen kleinen Einblick in, was los ist, aber ich habe immer noch nicht, warum die eine bestimmte Ausführung eine andere JRE als die andere wählt, oder wie man es beheben ...

Answer 1

es mit dem -verbose Parameter ausführen. Dies zeigt Ihnen, welche Java-Dateien wirklich verwendet werden.

java -verbose -cp C:\test\Execution\lib\*;C:\test\Execution\bin org.testng.TestNG C:\test\Execution\testng.xml 

Wenn aus irgendeinem Grund eine andere Java-Version in Ihrer QC-Umgebung verwendet wird, verwenden Sie den vollständigen Pfad Java auszuführen 8.

%java_home%/bin/java -cp C:\test\Execution\lib\*;C:\test\Execution\bin org.testng.TestNG C:\test\Execution\testng.xml 

Answer 2

Aus Ihrer Frage scheint es, dass die JDK-Version in Ihrem Remote-Host 1.8_91 ist, während die Version von Ihrem lokalen Host 1.7 ist. Korrigiere mich, wenn ich falsch liege.

Sie sollten die genaue Version von JDK überall dort verwenden, wo Sie diesen Code ausführen. Auch indem Sie die Maven-Compiler-Plugin verwenden, können Sie sicherstellen, dass der Code in Ihrer beabsichtigten Version kompiliert bekommen:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-compiler-plugin</artifactId> 
    <version>2.5.1</version> 
    <inherited>true</inherited> 
    <configuration> 
     <source>1.8</source> 
     <target>1.8</target> 
    </configuration> 
</plugin>