Modules with platform specific parts

[Samuel Audet]

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