Search code examples
javavirtual-machinealmhp-quality-centersystem-variable

Java UnsupportedClassVersionError (51), but only when executing command from remote machine

I have a simple TestNG setup, where I invoke a main class from command line. The tests runs perfectly.

I run them from command line, because I need to trigger the execution from HP Quality Center. This also works, as long as the QC-client triggering the command line, is running on the same location as the compiled test classes.

However, if I try to trigger the command line from a remote host, I get a minor major 51 error. I know that this means that the classes were compiled using java 1.7, and try to run using a lower level of java. What I do not understand is how and why it is using a lower version of java. a commandline java -version shows that the executing VM has a java 1.8_91 running. It used to have a 1.6_19, but I have upgraded it. I have also changed system variables for path and JAVA_HOME, and looked through other system variables, without finding anything that stands out.

How is it possible that the command line triggers two different versions of runtime java, when executed from local and remote host? How can i fix this, so that they use 1.8 in both cases?

PS, downgrading the compiled classes to 1.6 is not an option, as TestNG is depentend uopn 1.7

here is the exception thrown:

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

and the command itself:

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

lib includes some jar files, like Selenium and TestNG. testng.xml can contain configurations for exactly which tests to run within a class, but is empty in this case. The bin-folder holds the compiled java testcase itself, and some datafiles, used for parameters.

UPDATE: I should of course have run a simple java -version, from the start, but now I have, and here are the results:

When run from commandline directly, inside 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)

When executed from Quality Center Script, from browser inside the VM (here I need to save to file to see the actual output, and that only seems to work when using 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

When executed from Quality Center Script, from browser outside the VM (also 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]
....

After deleting the above mentioned Java folder, and all it's content, the output of the command was completely blank, in my text file.

this question, what is shared objects file?, gives me a little insight in what is going on, but I still don't get why the one particular execution selects a different JRE than the others, or how to fix it...

Solution

  • Execute it with the -verbose parameter. This will show you which java files are really used.

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

    If for some reason a different java version is used in your QC environment, use the full path to execute java 8.

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