NoSuchMethodError on one machine but not the other

Question

I have this application which you can run in batch mode with java macros. I have a mymacro.java that uses myjar.jar. For simplicity's sake I put them all in the same directory from which I am running the application, so the classpath is "./myjar.jar".

The command to run the application is:

theapplication -classpath "./myjar.jar" -batch mymacro.java

where the -classpath tag does what it advertises, i.e. override the classpath. Now this runs fine on my Windows XP PC. However, I get a NoSuchMethodError when running the exact same thing on a Linux cluster.

java.lang.NoSuchMethodError: 
com.foo.bar.baz.theMethod(Ljava/lang/String;Ljava/lang/String;)I

I can't figure this one out. Same .java, same .jar, same theMethod. The classpath can't get any simpler. Other methods in myjar.jar are being called without any errors. What could be going wrong?

FYI, I set the CLASSPATH environment variable to "." on both machines to rule out any conflicts.

EDIT

Output of java -version on my Windows XP PC:

java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode)

On Linux cluster:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)

Answer 1

Argh. The application contained a NetBeans module that basically contained the same code as an earlier version of my JAR file. So my java macro was preferentially accessing the methods in the older NBM, not those in my newer JAR file.

The error went away when I uninstalled the NBM.

Nice way to waste a full day of work!

Answer 2

I faced a similar issue once due to the file names of the JAR files used. In my case, I had multiple JAR files like a.jar, b.jar, m.jar and N.jar. A single class was duplicated in both m.jar and N.jar.

On Windows, everything used to work as N.jar was always getting loaded after m.jar. But after burning much midnight oil, I discovered that the issue on *nix was due to the fact that N.jar gets loaded first followed by a.jar, b.jar, m.jar as file names are case sensitive on *nix unlike on Windows.

Just make sure you don't have any similar issue.

Answer 3

Is

 com.foo.bar.baz.theMethod(Ljava/lang/String;Ljava/lang/String;)I

present in the new version of the jar? If it is not is probable that mymacro.java was compiled againt a version of the jar which contained it