native libs in modules

[Kevin Rushforth]

[including Alan and Mandy]

This came up briefly in a thread sent to jigsaw-dev [1], but with no 
real conclusion. I agree that it would be good to get a recommendation 
from the Jigsaw team.

After thinking about it more, here are my preferences:

* From the developer's point of view, they shouldn't have to know or 
care that some of our modules have platform-specific native code and 
others do not. Ideally, all an app developer should need is to declare a 
dependency on the needed module(s). Something like this:

     'javafx:javafx.controls:11'
     'javafx:javafx.graphics:11'   (although controls will depend on 
graphics, so this should be optional)

* For maven, the pom file should take care of downloading the jar 
file(s) for the specific platform; not sure if that is possible for 
gradle dependencies, but it would be ideal.

* For each module, we can package up the natives in one of two ways:

A) create a separate jar file per platform with the native code and the 
modular jar both in the same jar file. something like:

javafx-graphics-win-x64.jar
javafx-graphics-linux-x64.jar
javafx-graphics-osx-x64.jar

B) create one platform-independent modular jar file with all classes for 
all platforms, and also a separate jar per platform just for the native 
libraries:

javafx-graphics.jar  (with classes for all platforms)
javafx-graphics-natives-win-x64.jar
javafx-graphics-natives-linux-x64.jar
javafx-graphics-natives-osx-x64.jar

For either option there will need to be code that unpacks the natives.

I prefer option A if feasible, as I think it simplifies the build, 
hopefully without unduly complicating anything else. If it isn't 
feasible, then option B might be a good fallback.

Comments?

-- Kevin

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-April/013762.html


On 5/1/2018 5:34 AM, Johan Vos wrote:
> I'd love to hear a general recommendation from the jigsaw team as well.
> Clearly, there are a number of solutions, and as a developer, I easily 
> get confused if some frameworks do it with option A and others with 
> option B.
> So what is the preferred approach in general?
>
> It seems (given the large size of the webkit native library) there is 
> a growing consensus here for bundling native code inside 
> platform-specific jars?
>
> - Johan
>
> On Tue, May 1, 2018 at 7:38 AM Phil Race <philip.race at oracle.com 
> <mailto:philip.race at oracle.com>> wrote:
>
>     You are describing the situation today and making it into a
>     contract. You need to be sure that it is policed and enforceable.
>     Meaning there need to be tests to ensure it stays that way and
>     that it is not an unreasonable constraint on changes in the platform.
>
>     Also what if anything do the jigsaw team recommend ?
>
>     -Phil.
>
>     > On Apr 30, 2018, at 4:07 PM, Kevin Rushforth
>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>     wrote:
>     >
>     > The native libraries are quite large -- especially jfxwebkit --
>     and it does seem better to have per-platform jar files, at least
>     for the native libraries. The following modules could be
>     platform-independent since they have no natives:
>     >
>     > javafx.base
>     > javafx.controls
>     > javafx.fxml
>     > javafx.swing
>     >
>     > We would just need to test that the set of modular jar files for
>     each platform are the same, and then pick one (Linux?) to use for
>     generating the platform-independent jar files.
>     >
>     > The following modules have native libraries:
>     >
>     > javafx.graphics (*)
>     > javafx.media (*)
>     > javafx.web
>     >
>     > (*) - also has some differences in the set of class files that
>     are included depending on the platform
>     >
>     > So per-platform versions of the above would be needed to
>     accommodate the different native libraries.
>     >
>     > If it would help, the .class files could be always included for
>     all platforms, but there would be some additional effort to make
>     this work. Also, it might be just as easy to have the class files
>     and the natives in one downloaded jar file per platform, since at
>     least the natives need to be platform-independent. I'm far from a
>     maven expert, though, so I don't really know for sure which path
>     is easier.
>     >
>     > -- Kevin
>     >
>     >
>     >> On 4/30/2018 9:44 AM, Paul Ray Russell wrote:
>     >>  >I'm not sure I understand the question about
>     platform-specific jar files,
>     >>
>     >> Last time I worked on native specifics (which was to package up
>     RXTX dlls
>     >> for different OSs / in 64/32 bit) The easiest solution for pure
>     Maven
>     >> builds seemed to be, to package DLLs inside a jar. We then used
>     a profile
>     >> to control which DLL's were grabbed in different cases. And
>     surely for this
>     >> specific case, it would be better to split the native specifics
>     into
>     >> separate jars per OS to avoid a huge cross-OS download?
>     >
>