Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

changing the signature of a static method

 
Marilyn de Queiroz
Sheriff
Posts: 9067
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Java Cowboy
Saloon Keeper
Posts: 15495
43
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 9067
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 9067
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, yes and yes
 
Marilyn de Queiroz
Sheriff
Posts: 9067
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Marshal
Pie
Posts: 21514
84
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 9067
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
cool. Thanks, Henry. I appreciate that extra information. I'll check the deletion process more closely.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic