Loading libraries from memory or jar files

[Mike Hearn]

Hi Chris,

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.

If you want a solution right now check out my product Conveyor
<https://hydraulic.dev/>. 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.

https://conveyor.hydraulic.dev/16.0/configs/jvm/#native-code

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.

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!


On Thu, Jan 16, 2025 at 7:47 PM Chris Vest <mr.chrisvest at gmail.com> wrote:

> Hi,
>
> 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.
>
> I guess this is a limitation inherited from dlopen and LoadLibrary.
>
> 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.
>
> This old practice is starting to become problematic, since /tmp is now
> often mounted with noexec for security.
>
> So, is there some possible path forward that'll allow us to load libraries
> from e.g. a memory segment instead of a file?
>
> Thanks,
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20250117/4cba2325/attachment.htm>