Organization and symbol lookup for shared libraries

Per Bothner per@bothner.com
Wed Nov 10 19:04:00 GMT 2004


Bryce McKinlay wrote:
> 1. This forces .so names at runtime to match .jar names at compile time. 
> That might not always be true, for example, .jar file names often 
> reflect version numbers

As do .so files names, of course.
> - you might want to use a newer version of the 
> .so at runtime without recompiling the application.

You might want to *force* that, but you almost certainly don't
want that as the default.
For example I have code that compiles under JAXP 1.2 (i.e. jdk 1.4.x),
but doesn't under JAXP 1.3 (i.e. jdk 1.5.0) because they've added new
methods to existing interfaces.
> 2. How does the compiler express (to the runtime) that T should only be 
> loaded from L.so?

I didn't mean that. I meant that if the compiler finds T in L.jar,
it should put in the assembly file a request to link with L.so.
(I assume a single namespace, where the compiler compiles a reference
to a class T as symbol reference that is a mangled for of T, as
opposed to emitting a library call to search for "T".)
> 3. What if T isn't compiled? Classpath behaviour would potentially be 
> different depending on whether a bytecode or native version were run.

If T isn't compiled, you have to do a search. Conceptually, you can
search for .jar files, and once you find a match, load the .so file.
In practice, you might be able to only look at the .so files.
However, the search order of .so files should match that of .jar files,
including intelligent handling of multiple versions. I.e. if there
are multiple version of a .jar or .so, pick the "least specific" one.
E.g. prefer libfoo.so over libfoo.so.1 over libfoo.so.1.1, when
searching for a T. Then resolve the symlinks, and note in the
compilation result (.jar or .so or .exe) the specific library found.
When *running* a compiled application (compiled to .jar or .so) search 
for the *most specific* match that matches the one found at
compile-time, to minimize compatibility problems.
-- 
	--Per Bothner
per@bothner.com http://per.bothner.com/


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /