When do we get java.lang.NoSuchMethodError even when the jar/class has the particualar method

Question

I am using IText library to facilitate pdf export in an applet. During the export call it fails with following error java.lang.NoSuchMethodError: com.lowagie.text.pdf.PdfPTable.completeRow()V

I opened the Itext jar/PdfPtable.class in JD Decompiler and confirmed that the class has completeRow as a public method.

Can somebody explain the possible scenarios when a java.lang.NoSuchMethodError is thrown even when jar/class has it.

Here is the stack trace; may not be very helpful as most of the calls are our application specific.

Error while exporting to the CSV file - java.lang.NoSuchMethodError: com.lowagie.text.pdf.PdfPTable.completeRow()V com.blox.table.action.ExportToCSVAction.actionPerformed(ExportToCSVAction.java:193) javax.swing.AbstractButton.fireActionPerformed(Unknown Source) javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source) javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source) javax.swing.DefaultButtonModel.setPressed(Unknown Source) javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source) java.awt.Component.processMouseEvent(Unknown Source) javax.swing.JComponent.processMouseEvent(Unknown Source) java.awt.Component.processEvent(Unknown Source) java.awt.Container.processEvent(Unknown Source) java.awt.Component.dispatchEventImpl(Unknown Source) java.awt.Container.dispatchEventImpl(Unknown Source) java.awt.Component.dispatchEvent(Unknown Source) java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source) java.awt.LightweightDispatcher.processMouseEvent(Unknown Source) java.awt.LightweightDispatcher.dispatchEvent(Unknown Source) java.awt.Container.dispatchEventImpl(Unknown Source) java.awt.Window.dispatchEventImpl(Unknown Source) java.awt.Component.dispatchEvent(Unknown Source) java.awt.EventQueue.dispatchEvent(Unknown Source) java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source) java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source) java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source) java.awt.EventDispatchThread.pumpEvents(Unknown Source) java.awt.EventDispatchThread.pumpEvents(Unknown Source) java.awt.EventDispatchThread.run(Unknown Source) com.lowagie.text.pdf.PdfPTable.completeRow()V com.blox.table.view.GridTableModel$PdfExportWriter.writeNewLine(GridTableModel.java:7259) com.blox.table.view.GridTableModel.buildExportData(GridTableModel.java:3111) com.blox.table.view.GridTableModel.export(GridTableModel.java:2541) com.blox.table.view.GridTable.export(GridTable.java:1318) com.blox.table.action.ExportToCSVAction.exportToFile(ExportToCSVAction.java:248) com.blox.table.action.ExportToCSVAction.access$1(ExportToCSVAction.java:245) com.blox.table.action.ExportToCSVAction$Worker.exportToCSVFile(ExportToCSVAction.java:111) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) java.lang.reflect.Method.invoke(Unknown Source) spin.Invocation.evaluate(Invocation.java:175) spin.off.SpinOffEvaluator$1.run(SpinOffEvaluator.java:108) java.lang.Thread.run(Unknown Source)

Answer 1

perhaps there is another version of this class in your classpath before the version that you decompiled.
edit: Or you have updated the package, but have forgotten to either deploy it to your runtime classpath or you havent updated the compile classpath, ie your runtime env is out of sync with your compiletime env.

public void completeRow() was introduced in 2.0.5. you must have a version before 2.0.5 in your runtime classpath. if you are still experiencing this problem, please study the classpath for the startup of the process. as stated before, you are compiling with the 2.1.5 version.

Answer 2

It could be that a different version appears in your classpath or that the signature of that particular method has changed since your compiled your class

Answer 3

1. Usually such problems are cause if there is another version of the offending class in your classpath before the version that you used for compile (and that you decompiled as said before). This happens often as classpath issues are common, also with experts, esp. in containers, where the order of loaded libraries is unspecified.

   So lets say you use iText 1.a to in your IDE and you compile against. Then you deploy your application into some container, where iText 1.b is preinstalled. Preinstalled libraries take precedence and when b < a then you run into this kind of problem.

   In your case there is no container, but you could mix up library versions during packaging/deployment or have different classpaths for development and execution.

2. The jar is not in the classpath at runtime, only at compile time. But then you would get a NoClassDefFoundError when iText is accessed for the first time, which is not the case.

3. If iText itself would miss a third party library you would also get a NoClassDefFoundError when calling the method that needs the unsatisfied dependency.

Answer 4

It could also be that two versions of the jar appear in your applet classpath and the one that got loaded has a different signature than the one that your code was compiled with

Answer 5

That means two versions of the class PdfPTable are in your class path. Two jar files that you are using might have packaged different versions of the same class. Easy way to figure out is to do a jar -tf on the jar files in the classpath, and grep for your classname. Either remove the stale version or change the order of jar files in your class path.

Answer 6

I found out that one of the third party jar was bundling a older version of iText library