Loading native libraries from the classpath

[Maurizio Cimadamore]

On 17/01/2024 12:52, Pedro Lamarão wrote:
> Em qua., 17 de jan. de 2024 às 09:20, Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> escreveu:
>
>     I think here is more of the same: we know there's an issue when
>     trying
>     to build and deploy Java applications with native dependencies.
>     Panama
>     does something to help in that direction: if you target a C
>     library that
>     is installed on your system (e.g. using apt) you might not need any
>     heroics at all - because Panama can just load the system library
>     using a
>     library lookup [1] - a thin wrapper around dlopen which will find
>     system
>     libraries (by name) no matter where they are (same thing as dlopen
>     can
>     do). Of course, in some cases, a Java application might require a
>     specific library with specific version - such cases can be addressed,
>     for instance, by using a container (e.g. crate a docker image with
>     the
>     required installed dependencies, and run your Java app there).
>
>
> Some of these limitations are in the system`s dynamic loader.
> The loader cannot load a library from a "stream", only a "file path".
> If it were improved to be able to do so, the requirement for temporary 
> storage would be lifted.
> The appropriate library "stream" might be provided by a 
> LibraryProvider discovered with ServiceLoader where some property 
> matches the current architecture.
>
> -- 
> Pedro Lamarão

I think the "loading from a stream" problem is really a problem if you 
really do want to load a shared library from an archive file (e.g. a 
jar). If that becomes our "zero assumption", then yes, of course, the 
solution becomes something which allows to extract the library from the 
jar to somewhere else, and then load it (or maybe, by fixing OS - but I 
agree that's basically unrealistic - hoping that eventually the dynamic 
loader will be able to pick up the library from there).

In othe world we are today, where applications are loosely coupled 
together by adding jars on the classpath and then running some main 
entry point, I don't dispute that the current solutions are the best we 
can achieve.

But our world seems to be transitioning more and more towards a place 
where, perhaps, the components of an application are "assembled" 
together in the final system, which gets a final say on how things 
should behave. I see this tension not only for the topic of "loading 
native libraries" but, if you look at the many discussion on 
"--enable-native-access", on how an application specify the various 
flags that are required to run (e.g. to enable Linker, JNI, Unsafe, 
agents). Again, this makes me think that what we're reaching for is a 
slightly different world/paradigm (even if we're not 100% there yet).

Maurizio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240117/20ff4fba/attachment.htm>