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 
>> overhead.
>>> 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 
consider:
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...
Regards
Bryce