aspose file tools*
The moose likes Java in General and the fly likes changing the signature of a static method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "changing the signature of a static method" Watch "changing the signature of a static method" New topic
Author

changing the signature of a static method

Marilyn de Queiroz
Sheriff

Joined: Jul 22, 2000
Posts: 9044
    
  10
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 ]

JavaBeginnersFaq
"Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14114
    
  16

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.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Marilyn de Queiroz
Sheriff

Joined: Jul 22, 2000
Posts: 9044
    
  10
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

Joined: Sep 29, 2002
Posts: 1683
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.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Marilyn de Queiroz
Sheriff

Joined: Jul 22, 2000
Posts: 9044
    
  10
Yes, yes and yes
Marilyn de Queiroz
Sheriff

Joined: Jul 22, 2000
Posts: 9044
    
  10
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

Joined: Sep 29, 2002
Posts: 1683
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
Sheriff

Joined: Sep 28, 2004
Posts: 18748
    
  40

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 ]

Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Marilyn de Queiroz
Sheriff

Joined: Jul 22, 2000
Posts: 9044
    
  10
cool. Thanks, Henry. I appreciate that extra information. I'll check the deletion process more closely.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
 
wood burning stoves
 
subject: changing the signature of a static method