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

Question

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

this can help I think [link](http://stackoverflow.com/questions/10382929/how-to-fix-java-lang-unsupportedclassversionerror-unsupported-major-minor-versi) — viveksinghggits, May 19 '16 at 11:03
@viveksinghggits, thank you, but no. I have read through this post before, and it only confirms the parts that I have already described that I have tried. This error is far more specific than the general case of a minor major 51 error. — jumps4fun, May 19 '16 at 14:22
you need to make sure that the java used by HP QC is precisely the one you need (1.7). — ACV, May 23 '16 at 13:51
@ACV, how do I do that? Btw, the classes are definitely compiled with 1.7. they also clearly will run using JRE 1.8. The problem is that somewhere in the configurations, a version prior to 1.7 is used to run the classes, and I do not understand where it comes from, or why it is being used. — jumps4fun, May 23 '16 at 14:41
does QC have some sort of agent/service running on the remote host. if so, did you restart it after reconfiguring the java version on the remote host? — jtahlborn, May 23 '16 at 16:18
@jtahlborn, I do not know. I believe we have restarted everything we can restart, but it sounds like a good idea to check again. — jumps4fun, May 23 '16 at 16:22
Shared Objects File: http://stackoverflow.com/questions/4393940/what-is-shared-objects-file — tak3shi, May 24 '16 at 06:35
I need to check that @tak3shi. I did already link to that Q&A in my question, though ;) — jumps4fun, May 24 '16 at 08:10

tak3shi · Accepted Answer · 2016-05-24T11:16:18.753

1

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

edited May 24 '16 at 11:16

answered May 23 '16 at 14:51

tak3shi

2,305
1
20
33

You can also check `java -verbose -version` for curiosity. – tak3shi May 23 '16 at 15:20
Unfortunately, this does not solve my issue either. While manually typing the command in my VM CMD-promt, I get a whole bunch of java 1.8_91-lines. But that worked before as well. When trying to execute the command line from Quality Center, it now just freeze. I get no error, no success, nothing. It just stops, and keeps saying "Running...". I wish I knew why. – jumps4fun May 23 '16 at 15:27
I finally got a simple setup up and running, which ran a java -verbose - version, and I am updating the question immediately after posting this comment, to show the results. – jumps4fun May 23 '16 at 16:00
I have explored QC's settings extensively, but can not figure out where the path is set to java. However, I have realized, much thanks to your help previously, that I can call the full path of the java.exe, instead of the command `java`. Meaning that `D:\java\JDK8\bin\java.exe`, (i changed the path a little) instead of just `java` in the beginning of the sent command, forces my installed java version 1.8 to be used for execution. This makes my code work, and it is a very good workaround in my case. If you want to add this as a line in your answer, I will accept it :) – jumps4fun May 24 '16 at 11:03
Still does not work, if the path has whitespaces, but this is good enough! – jumps4fun May 24 '16 at 11:56

score -1 · Answer 2 · answered May 23 '16 at 14:15

-1

From your question, it seems that the JDK version in your remote host is 1.8_91, whereas the version of that in your local host is 1.7. Correct me if I'm wrong.

You should use the exact same version of JDK throughout the places where you are running this code. Also, by using the maven compiler plugin, you can make sure that the code is getting compiled in your intended version:

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

answered May 23 '16 at 14:15

Arka Ghosh

845
1
11
23

The java files are compiled using 1.7 correct. The remote host is running 1.8_91, correct. The error message states that the JRE used to run the compiled java classes is less than 1.7. 1.8 is backwards compatible with 1.7 compiled classes. In other words, You might be giving a lot of good tips, but yuo are in fact, not answering the question. If you read again, you can see that it behaves differently, depending on where i send the command line from. In other words, my 1.8 setup works, but at some point in my setup, it uses an older version than 1.7, and I have no idea where or why. – jumps4fun May 23 '16 at 14:39

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

2 Answers2