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.
However, the lack of a standard recommendation forces us to change the internal behavior every now and then. The latest change we made (removing automatic module names from empty modules [1]) caused issues in the 17 release, when developers compile JavaFX modular apps [2] Before we make many other changes, I would like to have a better view on what would be the recommended approach, so here is my summary. Suggestions are highly appreciated. Let's assume we have a component that contains some platform-independent Java code, some platform-dependent Java code, and some platform-dependent native code. To make the example concrete, let's use the javafx.graphics "module" from the OpenJFX project, which contains exactly that. There are a number of options, and before thinking about the best way for tools do deal with this situation, it would be good to have a recommended approach for those "hybrid" modules. 1. There is a single module (i.e. only one Module). All code, no matter on what platform or in which layer, will report the same value for class.getModule().getName(). This would lead to a single "javafx.graphics" conceptual module, but there will be a number of physical module files that are different (with different class files and native code). Those different modules should obvisouly be mutually exclusive in a runtime. 2. There are 2 modules: the platform-independent Java code goes into one module (let's call that javafx.graphics.api) and a second module is named javafx.graphics.platform and contains the platform-dependent Java code and the native code. In this approach, developers use the javafx.graphics.api module to compile against, and at runtime the javafx.graphics.platform module is required. Again, that second module will have a number of different physical implementations. As an extension to this, we might add the Service Provider Interface approach for loading platform-specific modules/bits at runtime. 3. We create one module for each platform. There is no "javafx.graphics" module in this case, but there is a "javafx.graphics.linux.aarch64" module for example. Doing so, there is a tight coupling between one conceptual module and one physical module. A clear drawback of this is that this is a real challenge at compiletime. Developers (who are only using generic API's) need to compile against a platform-specific module. 4. We use 2 artifacts: an "empty" one and then a number of implementation specific ones. The difference with option 2 is that the empty "module" exists solely for the purpose of tools, which can detect what implementation specific module(s) need to be loaded at compile/runtime. We currently use option 4, but in my opinion, option 2 would be the better approach. Thanks, - Johan [1] https://bugs.openjdk.java.net/browse/JDK-8264998 [2] https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-September/031934.html
