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

Thu Nov 4 13:58:00 GMT 2004

Andrew Haley wrote:
>Bryce McKinlay writes:
> > Andrew Haley wrote:
> > 
> > >Bryce McKinlay writes:
> > > > 
> > > > >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. 
> > >
> > >No.
> > >
> > > > Yes, unfortunately this is a well-known limitation of the existing
> > > > shared-library naming scheme.
> > >
> > >All you have to do is link explicitly against the shared library.
> > >
> > Well, yes, obviously that's the alternative
>>It is simply untrue to say that the jar can only contain one package.
>>OK, I misread/misinterpreted the question. It is, however, true that a 
shared library, using GCJ's naming conventions for runtime lookup of 
classes in shared libraries, must be named as a superset/intersection of 
all the packages contained in the jar it was made from. Doing that is 
not possible where you have a jar that contains classes in more than one 
top-level package, or where the higher level package names might 
conflict between different jars. ie: say you had a.jar which contains 
classes in org.foo and org.bar; and b.jar which contains classes in 
org.foo and org.zot. With the GCJ naming convention, you can't name 
those .so's in a way that a) doesn't conflict and b) is reasonably 
descriptive of the contents.
This is why I think a new scheme for runtime location/loading of the 
shared libraries is needed.
Regards
Bryce