native libs in modules

[Philip Race]

On 4/29/18, 10:05 AM, Johan Vos wrote:
> Now that the OpenJFX SDK that works with Java 11 is about to be released in
> EA, we should think about releasing the modules.
>
> In case you download the OpenJFX SDK, running an app goes like
> java --module-path $OPENJFXSDK/lib --add-modules javafx.controls your.app
>
> If you use gradle or maven, the same should be achieved using e.g.
> dependencies {
>      compile 'javafx:javafx.controls:11.0.0'
> }
>
> (ignore the naming and versioning for now)
>
> This will download the javafx controls module and its dependencies from
> e.g. maven central. The javafx controls module info declares a requires
> entry for javafx.base and javafx.graphics so those will be downloaded.
>
> The question is how the native libs should be downloaded. It is possible to
> bundle the native libs with the modules, but there are a number of options
> for dealing with platform-specific libraries:
>
> 1. javafx.graphics contains all native libraries for all platforms.
> 2. a generic javafx.graphics module containing java code only, plus N
> platform-specific modules (or jar) containing the native code. An example
> of how this is used is ND4J:
> https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-native/1.0.0-SNAPSHOT/

The java code is platform-specific too .. so I don't see how #1 would 
work and
#2 would seem to require some large amount of work and I don't think will
work either because you can't split packages acrosss modules which is 
what it
would probably mean.

-phil.
>
> To make it more complex, there are a number of options for e.g. prims
> leading to a number of native libs. Do we want to include all relevant
> options for all platforms?
>
> - Johan