• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Paul Clapham
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Liutauras Vilda
Saloon Keepers:
  • Tim Holloway
  • Carey Brown
  • Roland Mueller
  • Piet Souris
Bartenders:

changing the signature of a static method

 
Sheriff
Posts: 9109
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 9109
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 9109
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, yes and yes
 
Marilyn de Queiroz
Sheriff
Posts: 9109
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
author
Posts: 23959
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 9109
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
cool. Thanks, Henry. I appreciate that extra information. I'll check the deletion process more closely.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic