Modules with platform specific parts

[Kevin Rushforth]

We do have jmods available for download, but not in maven central. I'm 
not well-versed enough with maven / gradle support for jmods to know 
whether it would even be an option, but even we do have them, we still 
need the modular jars for the cases where the developer doesn't end up 
running jlink.

-- Kevin


On 9/15/2021 6:55 AM, Alan Bateman wrote:
> On 15/09/2021 09:45, Johan Vos wrote:
>> Hi,
>>
>> There have been discussions in the past about how to deal with
>> platform-specific parts (java code, native code, resources) in modules.
>> There is no standard for this, and afaik no recommendation. In the 
>> OpenJFX
>> project, we upload jars with module info to maven central, and we have
>> plugins for maven and gradle to deal with them at compiletime and at
>> runtime.
>>
> Project Panama and the foreign linker API may be another motivation to 
> re-visit this topic. One general concern is adding more complexity to 
> the JAR format. I could imagine platform specific sections adding 
> another dimension of complexity to MR JARs, modular JARs, modular MR 
> JARs, ...  Also every bag we nail on could have implications for 
> compile time, packaging time, jlink, and run-time.
>
> The position we took on this in JDK 9 is that modules can be platform 
> specific. There is a JDK-specific class file attribute named 
> "ModuleTarget" for the OS and/or architecture.  The jmod tool has an 
> option to specify the OS/arch when creating a JMOD. Post resolution 
> checks will catch issues where someone accidentally deploys a module 
> for the different OS/architecture. I have not looked at the JavaFX 
> modules recently but at some point I think they were packaged as JMOD 
> files and it might be that the platform was specified at that time. If 
> you've since moved to modular JARs then I could imagine this getting 
> lost.
>
> -Alan
>