Loading libraries from memory or jar files

[Mike Hearn]

Yes, I think you'd have to give users a script or similar to put the right
libraries into the JVM lib directory where System.loadLibrary will find
them. They can run that inside their Docker scripts or so after unpacking
or linking a JDK there. Or you can do as Mauruzio suggests and supply a
bunch of platform specific JMODs - boils down to the same thing.

On Fri, Jan 17, 2025 at 7:10 PM Chris Vest <mr.chrisvest at gmail.com> wrote:

> On macOS, we (Netty) do local codesign of the libraries before loading
> them, which has been working so far.
> I otherwise agree that it's desirable to move to a situation where we
> could instead rely on the libraries installed in a given system.
> Panama thankfully makes this possible, in theory anyway. The main problem
> we'd run into would be BoringSSL, which is our preferred TLS
> implementation, but they don't do releases and is typically not something
> you can install from e.g. a Linux package manager.
> As an open source library, we can't require that people use a commercial
> product for extracting the native binaries we ship. (They could, if they
> want, but we can't require it)
>
>
> On Fri, Jan 17, 2025 at 9:21 AM Mike Hearn <mike at plan99.net> wrote:
>
>> AFAIK Conveyor is the only tool that can (re)sign libraries inside jars
>> so you'll probably end up with either a mix of different signers or some
>> code being unsigned, unless you do a lot of manual scripting.
>>
>> If you restrict your view to only Linux then code signing doesn't matter.
>> But the general trend is the same: apps are expected to be immutable
>> collections of files that don't modify their install directory or load code
>> from temporary directories, home directories, etc. Docker, FlatPak, RPM/DEB
>> all assume this, as does MSIX on Windows and the .app bundle format on
>> macOS.
>>
>> You can try and fight this with ever weirder and more brittle hacks, or
>> accept the reality that apps should not be extracting shared libraries on
>> the fly from JARs in the first place. That was only ever a convenience for
>> developers and OS designers were never on board with it as a general
>> architectural pattern.
>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20250120/900b9337/attachment-0001.htm>