Java UnsupportedClassVersionError (51), mais uniquement lors de l'exécution d'une commande depuis une machine distante

Question

J'ai une configuration TestNG simple, où j'appelle une classe principale à partir de la ligne de commande. Les tests fonctionnent parfaitement. Je les lance à partir de la ligne de commande, car j'ai besoin de déclencher l'exécution à partir de HP Quality Center. Cela fonctionne également, aussi longtemps que le client QC qui déclenche la ligne de commande, s'exécute au même endroit que les classes de test compilées. Cependant, si j'essaie de déclencher la ligne de commande à partir d'un hôte distant, j'obtiens une erreur majeure mineure 51. Je sais que cela signifie que les classes ont été compilées en utilisant java 1.7, et essayent de fonctionner en utilisant un niveau inférieur de Java. Ce que je ne comprends pas, c'est comment et pourquoi il utilise une version inférieure de Java. une ligne de commande java -version montre que la machine virtuelle en cours d'exécution a un Java 1.8_91 en cours d'exécution. J'avais l'habitude d'avoir un 1.6_19, mais je l'ai amélioré. J'ai aussi changé les variables système pour path et JAVA_HOME, et j'ai regardé d'autres variables système, sans trouver quoi que ce soit qui se démarque.

Comment est-il possible que la ligne de commande déclenche deux versions différentes de runtime Java, lorsqu'il est exécuté à partir de l'hôte local et distant? Comment puis-je résoudre ce problème, de sorte qu'ils utilisent 1.8 dans les deux cas?

PS, déclasser les classes compilées à 1,6 est pas une option, comme TestNG est depentend uopn 1.7

ici est l'exception levée:

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 

et la commande elle-même:

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

lib inclut certains fichiers jar, comme Selenium et TestNG. testng.xml peut contenir des configurations pour exactement quels tests exécuter dans une classe, mais est vide dans ce cas. Le dossier bin contient le fichier de test java compilé lui-même et certains fichiers de données, utilisés pour les paramètres.

MISE À JOUR: Je bien sûr ai couru un java -version simple, dès le début, mais maintenant je dois, et voici les résultats:

Effectué à partir commandline directement, à l'intérieur 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) 

lorsqu'il est exécuté à partir du script Quality Center, depuis le navigateur dans la machine virtuelle (ici je dois enregistrer le fichier pour voir la sortie réelle, et qui semble ne fonctionner que lors de l'utilisation java -verbose -version):

[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 

Lorsqu'il est exécuté à partir du script Quality Center, à partir du navigateur en dehors de la machine virtuelle (également 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] 
.... 

Après avoir supprimé le dossier Java mentionné ci-dessus, et tout son contenu, la sortie de la commande était complètement vide , dans mon fichier texte.

cette question, what is shared objects file?, me donne un petit aperçu de ce qui se passe, mais je ne comprends toujours pas pourquoi une exécution particulière sélectionne un autre JRE que les autres, ou comment le réparer ...

Answer 1

Execute avec le paramètre verbose. Cela vous montrera quels fichiers Java sont vraiment utilisés.

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

Si pour une raison quelconque une autre version Java est utilisé dans votre environnement QC, utilisez le chemin complet pour exécuter java 8.

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

Answer 2

De votre question, il semble que la version JDK de votre hôte distant est 1.8_91, alors que la version de votre hôte local est 1.7. Corrige moi si je me trompe.

Vous devez utiliser exactement la même version de JDK dans les endroits où vous exécutez ce code. En outre, en utilisant le plugin compilateur maven, vous pouvez vous assurer que le code est compilé se dans votre version destinée:

<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>