Modules with platform specific parts

[Johan Vos]

Indeed, I didn't make it clear that we distribute JavaFX in 2 ways: the
"standalone SDK" and the "maven artifacts". There are no issues with the
standalone SDK approach, and I should have mentioned that.

But apart for the core JDK modules, the SDK approach makes it much harder
for developers to maintain dependencies. This is why we have tools like
maven, to deal with changing dependencies instead of requiring developers
to download, install and maintain SDK's for every dependency they have.

I believe we want to make sure the current SDK approach is not compromised,
while at the same time the "maven" approach is improved. Again, I'm not
sure this requires changes in the OpenJDK, but at least recommendations
would be useful.

- Johan


On Thu, Sep 16, 2021 at 2:00 AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Thanks for starting this discussion.
>
> One thing to point out is that for JavaFX we actually use two different
> approaches depending on whether you are talking about the maven
> artifacts or the downloadable artifacts.
>
> The maven artifacts, which is what Johan was primarily referring to, use
> option 4 as he mentioned. The modules are delivered as a set of modular
> jar files. Two things are worth noting. First, from an application POV
> there is only the javafx.graphics module; the tooling uses the dummy jar
> file, but ultimately chooses which of the platform-specific modular jars
> to load, each of which has the module name of "javafx.graphics". Second,
> there are no jmod files on maven central (although since we pack the
> native code in the jar files for the modular jars that go on maven
> central, it "sort of" works to point jlink at the platform-specific
> modular jars).
>
> The downloadable artifacts consist of an "sdk" bundle and a "jmods"
> bundle for each platform. Once downloaded and unzipped, the SDK contains
> a set of modular jars (along with the native libraries for that
> platform), while the jmods bundle contains a set of jmods. The modular
> jars in the SDK and the jmod files in the jmods bundle are all named
> simply "javafx.graphics", etc. So this is really option 1.
>
> If we had a blank sheet of paper (i.e., if we were defining the tools to
> work with modules as well as the modules themselves), option 1 with some
> standardized way of selecting the specific physical implementation for
> your platform would seem ideal to me. A library like JavaFX -- or any
> other library with platform-specific bits -- wouldn't have to split its
> modules into "api modules" and "implementation modules". This more
> closely matches what happens in the JDK itself for modules that are
> delivered with the platform. There is only a single "java.desktop"
> module regardless of platform, with different physical instances of that
> module for each platform (OS x arch).
>
> However, it seems that this option is running into an impedance mismatch
> with existing tools like maven, gradle, the various IDEs, etc. It seems
> like there ought to be a solution to this, but maybe there are just too
> many compatibility constraints with the existing tools.
>
> -- Kevin
>
>
> On 9/15/2021 1:45 AM, 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.
> >
> > 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
>
>