native libs in modules

[Phil Race]

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> 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?
>