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

Andrew Haley aph@redhat.com
Thu Nov 4 14:38:00 GMT 2004


Bryce McKinlay writes:
 > Andrew Haley wrote:
 > 
 > >Bryce McKinlay writes:
 > > > 
 > > > 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.
 > >
 > >Using the lib-foo-bar-baz.so scheme, yes.
 > >
 > > > This is why I think a new scheme for runtime location/loading of
 > > > the shared libraries is needed.
 > >
 > >Sure: all we need is to add the foo.jar --> foo.so mapping to the
 > >database.  I'm working on it.
 > >  
 > >
 > How about a class name --> foo.so mapping? 

That's not a good idea, because the same class name can exist in
multiple jars, so in order to keep things straight we'd need to have
multiple databases for multiple verions of packages.  This would be a
bad thing.

If we always map .jar -> .so or byte[] -> .so, the same database can
be shared by every gcj app that's installed on a system, regardless of
how many instances of foo.bar.baz we have compiled.  

Also, mapping class name -> .so runs into problems of version skew.

 > That way the .jars won't have to exist at runtime (for sane
 > applications, at least).

They won't have to exist: the .so will be searched first, and if the
classes or resources are found the .jar will never be opened.

Andrew.



More information about the Java mailing list