<!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>