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
