changing the signature of a static method

[Marilyn de Queiroz]

I changed the signature of a static method from
public static synchronized void simpleDbExecute(ExbJobContext jobContext, String statementName, String dbSource)
to
public static synchronized boolean simpleDbExecute(ExbJobContext jobContext, String statementName, String dbSource)

Now another class is getting an error when trying to call the method...
private void init(ExbJobContext ejc) {
DatabaseHelper.simpleDbExecute(ejc,"deleteAllOutageDet","dest.db.name");

ERROR: java.lang.NoSuchMethodError: com.ibm.esmrt.exb.util.DatabaseHelper: method
simpleDbExecute(Lcom/ibm/esmrt/exb/base/ExbJobContext;Ljava/lang/String;Ljava/lang/String;)V not found at
com.ibm.esmrt.app.abc.avail.DeliverOutageDetPreProcessor.init(DeliverOutageDetPreProcessor.java:33)

Any ideas on why this might be happening?
[ March 13, 2008: Message edited by: Marilyn de Queiroz ]

[Jesper de Jong]

You must also recompile the calling class. Now it is trying to find the old method (that returns void) and can't find it, so you get a NoSuchMethodError.

[Marilyn de Queiroz]

I'm pretty sure we did that. Our build script normally deletes all class files before each build, so both classes would have been built at approximately the same time. Looking ... the class I changed was compiled at 3:23 and the calling class was built at 3:24.

[Roger Chung-Wee]

Were JAR files built from the recompiled classes and, if so:

1. Were they completely rebuilt.

2. Are you sure that all previous JARs were deleted before running the latest JARs.

[Marilyn de Queiroz]

Yes, yes and yes

[Marilyn de Queiroz]

Perhaps it wasn't the signature change causing the problem, but
1) I can't think of any other reason that would cause this error under these circumstances.
2) It is interesting that all the other classes that use this class are not having any issues with it.

[Roger Chung-Wee]

You could revert the change, rebuild and rerun. If the failed class now runs, then this does suggest that it has not changed. Maybe there are two versions of the class, perhaps you need to double-check your classpath and build script.

[Henry Wong]

ERROR: java.lang.NoSuchMethodError: com.ibm.esmrt.exb.util.DatabaseHelper: method
simpleDbExecute(Lcom/ibm/esmrt/exb/base/ExbJobContext;Ljava/lang/String;Ljava/lang/String;)V

Well, it is definitely expecting the old signature. The "V" in the sigs states that nothing is returned -- which applies for void methods and constructors.

Henry
[ March 13, 2008: Message edited by: Henry Wong ]

[Marilyn de Queiroz]

cool. Thanks, Henry. I appreciate that extra information. I'll check the deletion process more closely.

[Ilja Preuss]

There really is just one possible cause for this kind of error: there still is an old version of the client class in the classpath.

We once had such a problem with one customer. We finally found out that when he got a new version of the jar files, he *renamed* the old ones (some kind of manual version control) and let them stay in the same folder. Our start script would just grab all the jar files in the folder and put them on the classpath. The JVM then uses the classes from the jar files that are found earlier in the classpath.