Project Panama & dynamic library loading

[Mark Raynsford]

On 2019-09-16T12:55:20 +0100
Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:

> Something along these lines might well be required yes - although AFAIK 
> not even OSGi can protect you from sonames and missing dependencies (as, 
> under the hood, it will still delegate to System::loadLibrary). Also, 
> while not required, I think OSGi typical use case will be to co-package 
> the required native libraries in a given bundle, which I don't think 
> it's exactly the case we're discussing here? E.g. I took a look at 
> lwjgl-opengl and that seems to load libGL that comes installed in the 
> system - outside the bundle, with a call to dlopen (on Linux). So, if 
> the system library is not installed correctly (e.g. the system has 
> libGL.so.1, but not libGL.so), I think that approach will still run into 
> issues - although I agree that having the ability to co-bundle multiple 
> platfrom-dependent shared libraries onto the same artifact is nice.
> 

Heh, yes, that particular library was perhaps not the best example I
could have picked. It was the one I had closest to hand. :)

LWJGL is a non-OSGi project that has been separately OSGi-ized. The
explicit, external load of libGL.so is because that library is part of
the system graphics drivers and so can't be distributed.

I take your point about the rest. I misunderstood and thought that the
problem was being unable to sensibly find bundled libraries.

-- 
Mark Raynsford | http://www.io7m.com