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

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 2

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 3

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