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

[Bryce McKinlay <mckinlay at redhat dot com>]

Andrew Haley wrote:

> > 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.
>  
Good point, but doesn't this (version skew) problem exist regardless of 
whether we're mapping .jar's or class files? In either case, some kind 
of classpath setting is presumably required to determine the search 
order for classes, if an application cares.

> > 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.
>  
But, assuming the application can't/doesn't explicitly link all the 
.so's it uses, how do we find the .so's? For performance reasons, we 
don't want to have to dlopen every .so we see on the chance that it 
might contain a required class. By using a cache, we wouldn't have to 
open them unless something changes.

Bryce