Project Panama & dynamic library loading

[Mark Raynsford]

On 2019-09-16T10:53:09 +0100
Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:

> I agree with this analysis.
> 
> One addition - it's not really that jextract cares about sonames - it's 
> just that if you call
> 
> System::loadLibrary("foo")
> 
> and you are on Linux, the VM will try to load:
> 
> libfoo.so
> 
> on all the paths that are part of the native library path.
> 
> If you want something different, then there's the more general 
> System::load which takes a full _patth_ (not a libname), which can of 
> course contain sonames and all.

Just a quick question: Is anyone here familiar with how OSGi handles
this? In my opinion, this stuff already seems to be a solved problem
there.

Bundles (jar files in OSGi speak) contain native libraries directly,
and contain metadata in the MANIFEST.MF file that explain which native
libraries match each arch/os combination. For example:

Bundle-NativeCode:\
  lwjgl_opengl32.dll;osname=Win32;processor=x86,\
  lwjgl_opengl.dll;osname=Win32;processor=x86-64,\
  liblwjgl_opengl.so;osname=Linux;processor=x86-64,\
  liblwjgl_opengl.dylib;osname=MacOSX;processor=x86-64

That's an extract from the OSGi bundles from the LWJGL project. The
Bundle-NativeCode declaration specifies which native libraries are
included, and which should be loaded in a given situation. You can see
that it states that the runtime should load lwjgl_opengl32.dll if the
current platform is Windows on x86. It should load liblwjgl_opengl.so
if the current platform is Linux on x86-64, etc. It's also possible to
state that a particular platform/arch doesn't require a native library.

The runtime transparently extracts and arranges paths as necessary so
that calls to System::loadLibrary("lwjgl_opengl") work correctly.

I believe that JBoss modules work similarly.

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