Organization and symbol lookup for shared libraries
Wed Nov 10 17:13:00 GMT 2004
Per Bothner wrote:
> Bryce McKinlay wrote:
>> Its also important to remember that all of this only happens if an
>> attempt is made to resolve a class that wasn't explicitly linked.
>> "hello world", nor any app that only uses libgcj or other libraries
>> that are explicitly linked with "-l", will not incur any of this
> Also, if at compile-time we reference class T using L.jar, at run-time
> we ahould only look in L.so.
I can see how this behaviour would be an advantage in some situations,
but I'm not sure how well it would work in practice. Some issues to
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 - you might want to use a newer version of the
.so at runtime without recompiling the application.
2. How does the compiler express (to the runtime) that T should only be
loaded from L.so?
3. What if T isn't compiled? Classpath behaviour would potentially be
different depending on whether a bytecode or native version were run.
I guess all of these have possible work-arounds, but I wonder if the
benefits are worth the potential hassles...
More information about the Java