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
