>>>>> "Herve" == Herve Chang <Herve.Chang@xxxxxxxx> writes: Herve> => building classpath from sources do not give me any xmlj.dll file Herve> needed for my usage (I'm using classpath on a windows mobile Herve> environment). If someone have already built the shared library Herve> xmlj.dll (or either xmlj.so file), I would kindly appreciate these Herve> infos :-) FWIW I haven't heard of anybody doing this. Herve> => If not, I am wondering if I am the first trying to use XML or Herve> XML/DOM in classpath :-) ? I don't recall doing it myself, but I am sure it has been done. Herve> a) IMO, the UnsatisfiedLinkError catch block is not at the right Herve> place. It is currently in gnu.xml.dom ImplementationSource class (as Herve> Tom said) which is a client class. It should rather be directly in the Herve> class that calls System.load() (gnu.xml.libxmlj.util.XMJ) something Herve> like It is a bit goofy, but I don't think it is incorrect. Herve> b) Morover, another problem is that, the success/failure of libxmlj Herve> loading is not considered. There should be a flag to indicate that Herve> either native loading has succeeded or not. Otherwise, there would be Herve> some ExceptionInInitializerError (as in the stacktrace), as some Herve> others class may rely on libxmlj. There shouldn't be any direct dependencies on this code -- if there are then that is a bug. The whole point, AIUI, is that this provider is optional. Herve> Caused by: java.lang.ExceptionInInitializerError Herve> at java.lang.VMClass.forName (Native Method) Herve> at java.lang.Class.forName (Class.java:161) Herve> at gnu.xml.dom.ImplementationSource.<clinit> (ImplementationSource.java) Herve> at gnu.xml.dom.ImplementationSource.<clinit> (ImplementationSource.java) Herve> at java.lang.VMClassLoader.loadClass (Native Method) Herve> ...25 more Herve> Caused by: java.lang.UnsatisfiedLinkError: Native library `xmlj' not Herve> found (as file `xmlj') in gnu.classpath.boot.library.path and Herve> java.library.path Herve> at java.lang.Runtime.loadLibrary (Runtime.java:763) Herve> at java.lang.System.loadLibrary (System.java:529) Herve> at gnu.xml.libxmlj.util.XMLJ.init (XMLJ.java:92) Herve> at gnu.xml.libxmlj.dom.GnomeDocumentBuilder.<clinit> Herve> (GnomeDocumentBuilder.java) Herve> at gnu.xml.libxmlj.dom.GnomeDocumentBuilder.<clinit> Herve> (GnomeDocumentBuilder.java) Herve> at java.lang.VMClass.forName (Native Method) Herve> ...29 more Ah, I see the problem. ImplementationSource is catching UnsatisfiedLinkError, but Class.forName is actually wrapping it in ExceptionInInitializerError. By my reading of the VM Spec: http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#24237 (see point #9) I think this is a VM bug. In particular Error and its subclasses should not be wrapped in ExceptionInInitializerError. Tom
