<!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 16/01/2024 01:43, Sebastian Stenzel
wrote:<br>
</div>
<blockquote type="cite" cite="mid:4A1D7492-E242-4A39-AD06-C31F6365CA53@gmail.com">
<pre class="moz-quote-pre" wrap="">Hi,
I basically agree with this being an application packaging problem, however the jlink mechanism you mentioned only works with jmods, not with jar files or am I mistaken?
The problem with jmods is that afaik you can't publish them to Maven Central, ruling out this option for library developers. Unless you want to force downstream users to download your library manually like we did in medieval times. 😉 Maybe this needs to be solved by the Maven team, making jmods easier to distribute, but they are very careful when it comes to allowing deployment of further file formats on Central, as can be seen with Sigstore. [1]</pre>
</blockquote>
<p>Yeah, unfortunately that is the conundrum - which is why I didn't
just say "jmods for the winner" :-)</p>
<p>This seems a general area where modules and custom JDK images
could add a lot of value, simplifying testing and launcher
configurations. Unfortunately none of it works out of the box, not
with IDEs, not with existing build tools (in jextract we had to do
a couple of hacks to be able to integrate jlink in our workflow),
which leads to the current chicken-and-egg problem.</p>
<p>That said, I'm starting to see a push towards trying to ship
monolithic application images [1] where application and supporting
libraries (native and not) are provided in a single executable
launcher. If efforts like these prove successful, they might
indicate a way forward from where we are now.</p>
<span style="white-space: pre-wrap">
</span>
<blockquote type="cite" cite="mid:4A1D7492-E242-4A39-AD06-C31F6365CA53@gmail.com">
<pre class="moz-quote-pre" wrap="">
So in my opinion the extract-from-jar approach is merely a workaround for a missing proper solution.</pre>
</blockquote>
<p>Yes!</p>
<p>Maurizio<br>
</p>
<p>[1] -
<a class="moz-txt-link-freetext" href="https://mail.openjdk.org/pipermail/leyden-dev/2023-February/000106.html">https://mail.openjdk.org/pipermail/leyden-dev/2023-February/000106.html</a><br>
</p>
<blockquote type="cite" cite="mid:4A1D7492-E242-4A39-AD06-C31F6365CA53@gmail.com">
<pre class="moz-quote-pre" wrap=""></pre>
</blockquote>
<p></p>
<blockquote type="cite" cite="mid:4A1D7492-E242-4A39-AD06-C31F6365CA53@gmail.com">
<pre class="moz-quote-pre" wrap="">
Cheers,
Sebastian
[1] <a class="moz-txt-link-freetext" href="https://central.sonatype.org/news/20220310_sigstore/">https://central.sonatype.org/news/20220310_sigstore/</a>
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Am 15.01.2024 um 19:10 schrieb Maurizio Cimadamore <a class="moz-txt-link-rfc2396E" href="mailto:maurizio.cimadamore@oracle.com"><maurizio.cimadamore@oracle.com></a>:
Hi,
extracting libraries from jars into some temp folder, and loading from there is indeed a common use case.
That said, the logic to support this is rather fragile, it is not uncommon to run code in machines which don't have write access to /tmp - in which case such an approach would fail.
For this reasons, at the time being we have not provided explicit support for this mode of operation - we tend to view this more as a packaging problem, rather than an API one. For instance, when linking modules into a custom JDK image (using jlink) it is possible to bring in custom native libraries as well, which greatly simplifies running/testing an application (we use this technique for jextract itself [1]). But I understand that much of the toolchain (gradle, maven et. alias) are mostly written with jars in mind, so this might not be an option.
Maurizio
[1] - <a class="moz-txt-link-freetext" href="https://github.com/openjdk/jextract/blob/master/build.gradle#L97">https://github.com/openjdk/jextract/blob/master/build.gradle#L97</a>
On 15/01/2024 16:51, Jeffrey Yemin wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi,
It seems fairly common for modules published to Maven Central to embed native libraries in the .jar file itself, in order to avoid the complications of applications having to install the native libraries themselves.
Some libraries (including one, <a class="moz-txt-link-freetext" href="https://github.com/mongodb/libmongocrypt/tree/master/bindings/java/mongocrypt">https://github.com/mongodb/libmongocrypt/tree/master/bindings/java/mongocrypt</a>, that I maintain for MongoDB) delegate the extraction of the appropriate native library to JNA, while others that use JNI directly (like <a class="moz-txt-link-freetext" href="https://github.com/xerial/snappy-java">https://github.com/xerial/snappy-java</a>) implement the extraction via custom code (see <a class="moz-txt-link-freetext" href="https://github.com/xerial/snappy-java/blob/v1.1.10.5/src/main/java/org/xerial/snappy/SnappyLoader.java#L53-L56">https://github.com/xerial/snappy-java/blob/v1.1.10.5/src/main/java/org/xerial/snappy/SnappyLoader.java#L53-L56</a>).
As the community starts to move away from JNI and JNA to the new Foreign Function API defined in JEP 454, are there any plans to support the automatic loading of native libraries from the classpath in the Java platform itself?
Thanks,
Jeff Yemin
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</body>
</html>