bundling native libs in jars or modules

Tom Schindl tom.schindl at bestsolution.at
Thu May 17 19:50:55 UTC 2018

Did you check how SWT does addresses the problem? If you run it outside of OSGi it needs to deal with this problem as well.


Von meinem iPhone gesendet

> Am 17.05.2018 um 21:25 schrieb Johan Vos <johan.vos at gluonhq.com>:
> Note: This is different from what is discussed in
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021762.html
> The following text is about bundling native code within a jar, and doesn't
> talk about how to deal with platform-specific libraries in generic jar
> files.
> At this moment, the standalone SDK for JavaFX 11-ea works fine, and javafx
> apps can be executed since the javafx jars will load the required native
> code from the libs that are part of the SDK.
> When we want to download the javafx modules as modules (or jars with
> module-info), we don't have a local SDK with native libraries. The native
> libraries need to come with the downloaded jar. There are a number of
> options to do this, and a number of ongoing discussions (e.g. see
> http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001541.html).
> In summary, jmods already have support for native code but they are not
> scoped at runtime, and jars don't have a standard way for supporting native
> code.
> I hope there will be a long-term solution for this in the VM in the future,
> but clearly we can't rely on this for the 11 release.
> Hence, we need to provide some JavaFX-specific fixes.
> Just to try the mechanism, I created a quick (and dirty) workaround in the
> NativeLibLoader. I committed it to a nativelibs branch of my openjfx fork:
> https://github.com/johanvos/openjdk-jfx/commit/f2c4c57a6197634e9c3bc1298ea14700057155a3
> The good thing is that all JavaFX native lib loading is already delegated
> to the NativeLibLoader, so I only had to patch one file.
> I modified the generated javafx.graphics.jar to include all libs that are
> generated (something that can be automated in a gradle task), and could
> successfully run javafx apps using
> java -p /path/to/my/jars --add-modules javafx.controls
> without specifying java.library.path or native libs or so.
> This works for jars that I put myself on the classpath, hence it should
> also work for jars downloaded from maven central etc.
> In case there will be a standard for bundling native libs with jar files in
> a future JVM, we can remove this hack. But even in the meantime, there are
> better solutions.
> One of the best options I think we should consider is using JavaCPP (
> https://github.com/bytedeco/javacpp)  . The main author of JavaCPP, Samuel
> Audet (in cc) describes here (
> https://github.com/tensorflow/tensorflow/issues/18397#issuecomment-381371636)
> why my hack will fail on Windows.
> Another advantage of JavaCPP is that it is proven to work on ios and
> Android as well. Actually, that would allow us to get rid of the
> ios-specific code that is currently in NativeLibLoader.java.
> Again, this is only tackling the issue of bunding native code with jars and
> not dealing with platform-specific resolution (although JavaCPP can help
> there as well).
> - Johan

More information about the openjfx-dev mailing list