Organization and symbol lookup for shared libraries

Per Bothner per@bothner.com
Fri Nov 5 18:02:00 GMT 2004


Andrew Haley wrote:

 > That seems reasonable, but it's a bit more complex than having a
 > java.ext.dirs path that simply contains .so and .jar.  Can you think
 > of any circumstances where you would want to add a directory that
 > contains .jar files to the path but you would *not* want the .so files
 > in the same directory?

Well, .jar files should probably be in /usr/share (as being portable),
while .so should probably be in /usr/lib (being not).  Of course one
coudl set up symlinks, but it would be awkward to have to do this
for each archive.  Directory symlinks, however, would be ok.

We could have have:
/usr/share/java/ext - contains jars
/usr/share/java/gcj - a symlink to /usr/lib/gcj which contains .so's.

The key to usability is not that they're in the same directory,
but that it is easy to map from the .jar to the .so.

We also do need to handle multiple versions, both jars and so-s.
If I compiled an application using foo-2.5.jar on my classpath,
at runtime the default should be to use libfoo-2.5.so, even if
foo-3.0 has been installed since.

If both foo-2.5 and foo-3.0 are installed at compile time, there
should be symlinks selecting a default - presumably 3.0.  If I
compile in this situation without special flags, I should get the
default foo-3.0.  When I later execute that, it should use the
version compatible with 3.0, using conventions derived from
.so selection (which I'm not familiar with).

There should also be a way at compile-time to over-ride the
default - perhaps my application needs foo-2.5 since it is
incompatible with foo-3.0.  Or I'm am a commerical developer,
and all my testing has been on foo-2.5.  I don't want to support
people accidentally using foo-3.0.  (I believe there is a way
in the .jar to specify such requirements.)

And there should be a way of overriding the default at run-time.

Some of these issues where discussed on the debian java list
a while ago.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/



More information about the Java mailing list