I'm using the org.apache.xerces 1.4 implementation on WinNT. When I tried to compile on a jdk 1.2.2 VM I would get a NoSuchMethodError. It compiled fine with a 1.3.0 VM. But now, when I try to run the compiled code on a Unix platform using a 1.3.1 runtime, it throws the same exception - NoSuchMethodError. See also http://lists.xml.org/archives/xml-dev/200101/msg00805.html where Huaxin Zhang reported receiving serialized forms in his exception messages thus: Exception in thread "main" java.lang.NoSuchMethodError: > org.w3c.dom.Document: method > importNode(Lorg/w3c/dom/Node;Z)Lorg/w3c/dom/Node; not found > at test.main(test.java:45) I rated this bug as critical because importNode is a truly crucial method.
sorry, I meant Document.importNode(Node node, boolean bool);
I've just downloaded the source for 1.4.4 and, looking at DocumentImpl.java, it appears that there is NO SUCH METHOD! How did your compiler manage to implement Document? How did mine? Looking futher I notice this implementation has been around since 19980818. Does no-one else splice xml?
whoops. how embarrasing. I've found CoreDocument.importNode(Node node, boolean deep, Hashtable reversedIdentifiers).
The method throws NoSuchMethodError. The method does exist on CoreDocumentImpl. The method declares only a DOMException to be thrown. NoSuchMethodError extends IncompatibleClassChangeError extends LinkageError. It will bypass normal Exception handling. I suggest that one or more classes on which importNode depends have changed incompatibly in the course of the Xerces project. Since this is an interface issue, OS & platform differences would only be of concern if different classes were deployed on different platforms(IO classes?). I reiterate that this method has worked fine on win2k with jdk1.3.0. At present I'm getting trouble with Xerces 1.4.0 on a Linux box(Debian 2.2 (potato), Kernel is 2.2.17-SMP. Hardware is duel p3 550's, 512MB ECC ram ) running a 1.3.1-b24 runtime. The file.encoding.pkg=sun.io The file.encoding=ANSI_X3.4-1968