Compiling XML parsers (xerces, Dom4j, etc...)

Thu Nov 4 01:56:00 GMT 2004

Ray Auge wrote:
>First, gcj can in fact compile jar files into usable libraries (as we
>all know or have read), but there are limitations which are not clearly
>advertised or documented (at least not in any obvious way).
>>1) The first limitation is that in order to get working libs from jars
>you have to work with this assumption. The jar can only contain one
>package. 
>
Yes, unfortunately this is a well-known limitation of the existing 
shared-library naming scheme. We've been looking at deprecating/removing 
this and moving to something that doesn't rely on the name of the shared 
library in order to find classes. One possibility is to have GCJ 
maintain a system-wide registry of shared libraries with a hashtable 
mapping the classes they contain to shared libraries. This would be 
somewhat similar to the cached class-map work Andrew has been doing on 
the BC branch (jv-dbtool), except the mapping would be of class names to 
shared objects rather than hashes of class data.
>2) The second limitation is in packages that involve the inclusion of
>resource bundles (like most XML parsers do, as in the configurations).
>This I haven't dealt with yet and was the basis of my own questions
>which I was hoping to have answered on this list (until I saw these
>other related questions).
>>You can compile resource bundles into shared libraries by way of the 
--resource argument to GCJ. Its likely that GCJ needs some 
improvement/bug-fixes in this area, however - I suspect resources 
contained in .jar's may not be compiled automatically?
Bryce