Issues using The Grinder load testing framework

Question

I'm running into problems trying to use The Grinder. The tutorial on the site tells me to run "StartAgent.bat", which looks like this:

call "C:\Documents and Settings\dkeller\Desktop\Grinder\setGrinderEnv.bat"
java -cp %CLASSPATH% net.grinder.Grinder %GRINDERPROPERTIES%

When I open the Command Console and try to run it, I get this error:

"C:\Documents and Settings\dkeller\Desktop\Grinder>java -cp "C:\Documents and Settings\dkeller\My Documents\grinder-3.4"\lib\grinder.jar;"C:\Documents and Settings\dkeller\My Documents\grinder-3.4"\lib\grinder.jar;"C:\Documents and Settings\dkeller\My Documents\grinder-3.4"\lib\grinder.jar;"C:\Documents and Settings\dkeller\My Documents\grinder-3.4"\lib\grinder.jar; net.grinder.Grinder "C:\jython2.5.2\grinder.properties"
Exception in thread "main" java.lang.UnsupportedClassVersionError: net/grinder/G
rinder (Unsupported major.minor version 49.0)
        at java.lang.ClassLoader.defineClass0(Native Method)
        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$100(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)
        at java.lang.ClassLoader.loadClassInternal(Unknown Source)"

Yikes. Not totally sure what the problem is. Thinking it might be an issue with java versions, I made sure to update to the latest, but I'm not sure if it worked correctly. Here are some commands I ran, so you can see what I mean.

"java -version" returns

java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

and "javac -version" returns

javac 1.6.0_26

Any help would be much appreciated, as I'm not sure what to try next.

score 1 · Accepted Answer · answered Jun 13 '11 at 16:02

1

Looks like your PATH environment variable is the problem. It's probably easiest just to edit that to have your JDK's bin directory in the PATH of the "user" part of the environment variables, so it comes before anything else which might contain java.exe.

Basically when you run java -version, you want it to show the same version number as javac -version.

Alternatively, you might consider uninstalling Java 1.4.2 unless you're still using it for something else...

answered Jun 13 '11 at 16:02

Jon Skeet

1,421,763
867
9,128
9,194

Thanks for the answer, Jon. When I "set classpath=C:\Program Files\Java\jdk1.6.0_26\bin", and then run java -version again, I get the same results as my above post. Here is my PATH, straight from the enviornment variables: "C:\Program Files\Java\jdk1.6.0_26\bin;C:\Program Files\Java\jre6\bin". As you can see, the JDK and JRE are both version 6. As far as deleting my old Java version goes, I can't find it anywhere. Do you know where it would be? It's not in the Java folder of my programs. – Duncan Jun 13 '11 at 16:19
@Duncan: Not your *classpath* - your *path*. They're very different. If your path is going straight to the JDK 1.6 directory, I can't explain why you'd see Java 1.4.2. Try running `dir /s java.exe` from `c:\` - I wonder whether something else you've got installed uses an embedded installation... – Jon Skeet Jun 13 '11 at 16:22
Interesting. Here's the file I think is causing the problem: " Directory of C:\Oracle\product\10.1.0\Client_1\jre\1.4.2\bin 12/11/2003 07:47 PM 24,681 java.exe 1 File(s) 24,681 bytes." Do you think it's safe to delete that folder? I don't believe I'm using it for anyting. If not, what do you think I should do? – Duncan Jun 13 '11 at 16:27
@Duncan: If you need the Oracle client installed, I don't think I'd mess with that. But if you put the JDK directory earlier in the path than anything from Oracle, that *shouldn't* be a problem. – Jon Skeet Jun 13 '11 at 16:32
Beautiful. java -version and javac -version match now. What really confused me is that there was a PATH variable, and a Path variable. The Path one is what I neede to edit. Everything is working now. Thanks again, Jon, you've been a huge help. – Duncan Jun 13 '11 at 16:36
@Duncan: Eek - environment variables are usually case-insensitive; there would probably be one system one and one user one, and they'd be concatenated together. Oh well, I'm glad you've worked it out :) – Jon Skeet Jun 13 '11 at 16:47

Issues using The Grinder load testing framework

1 Answers1