Loading libraries from memory or jar files

[Chris Vest]

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/20250117/b393c61e/attachment.htm>