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