<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 17/01/2024 12:52, Pedro Lamarão
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAC8PkgFxxgbZvfSKxeGFJ9QSVoy8KWhmwUQkb9i7mpZb6yRNaQ@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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>
</blockquote>
<p>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).</p>
<p>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.</p>
<p>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).</p>
<p>Maurizio<br>
</p>
</body>
</html>