We can publish JMODs, or any other binaries for that matter, on Maven
repositories, for example, here's a random one I've just pulled out:
https://search.maven.org/artifact/com.github.nullterminated/trylambda/1.4/jmod
But why do we need to maintain 2 different sets of archives containing
essentially the same thing? Android has been doing something similar:
When native libraries are involved, we need to feed it AAR files instead
of normal JAR files for end users to get all the benefits of the
platform. However, we don't need to do that in the case of, for example,
OSGi. With some additional metadata and a lot of hacking, we can get it
to manage JAR files containing native libraries just fine, so it *is*
possible. JAR is the common denominator, JMOD is not.
If it wants to remain relevant, OpenJDK should really consider having a
broader discussion about this. That is, rather than simply saying that
everything is hopelessly broken, and that we have to throw everything
out the window, let's maybe try to fix the "old and broken", because
redoing everything from scratch just isn't going to happen. If the Java
platform cannot maintain some semblance of backward compatibility,
developers are going to be tempted to just abandon it and start new
projects with something else.
Please, please, do consider fixing the JDK instead of talking about
coming up with incompatible "solutions"!
Samuel
On 9/16/21 9:13 AM, Kevin Rushforth wrote:
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
