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.
Tom Von meinem iPhone gesendet > Am 17.05.2018 um 21:25 schrieb Johan Vos <johan....@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
