<div dir="ltr">Hi Chris,<div><br></div><div><div>You don't want to try and load libraries from memory. I know it seems superficially attractive but beyond the fact that no operating system supports it, hacks that make it possible on Windows trigger antivirus engines. Windows and macOS assume your code will be signed and if you're extracting libraries from JARs then you won't be doing signing properly. It's also obviously much better for startup time to have the libraries on disk ready to go, where they can be demand paged.</div><div></div></div><div><br></div><div>If you want a solution right now check out my product <a href="https://hydraulic.dev/">Conveyor</a>. It will extract native libraries from JARs, place them in lib, set up system properties for popular libs to ensure they get found, delete the libs that are for the wrong target OS/architecture from inside the JARs, sign them, and do a bunch of other stuff. Just turn on the app.jvm.extract-native-libraries key.</div><div><br></div><div><a href="https://conveyor.hydraulic.dev/16.0/configs/jvm/#native-code">https://conveyor.hydraulic.dev/16.0/configs/jvm/#native-code</a></div><div><br></div><div>So - during development your apps will extract stuff to /tmp or $HOME or wherever. At deployment time the libraries will be a part of your app package. Type "conveyor run" to build the app locally and run it using the native OS directory layout.</div><div><br></div><div>There's also support for complex cases like JCEF where the JAR will actually try and download the native code on the fly at startup - a bad idea for real deployment scenarios!</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2025 at 7:47 PM Chris Vest <<a href="mailto:mr.chrisvest@gmail.com">mr.chrisvest@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>SymbolLookup and the older System.load/loadLibrary all make the assumption that any library we wish to load is located in a file on the, er, "native" file system.</div><div><br></div><div>I guess this is a limitation inherited from dlopen and LoadLibrary.</div><div><br></div><div>Many Java projects that include native code, then tend to package their native libraries as part of their jar files, and extract them to /tmp, or the like, before loading them.</div><div><br></div><div>This old practice is starting to become problematic, since /tmp is now often mounted with noexec for security.</div><div><br></div><div>So, is there some possible path forward that'll allow us to load libraries from e.g. a memory segment instead of a file?</div><div><br></div><div>Thanks,</div><div>Chris</div></div>
</blockquote></div>