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
