Why does the plugin not work with automatic modules?

[koppor]

When using it in my project, I get

jlink failed with: Error: automatic module cannot be used with jlink: langchain4j.core from file:///C:/Users/koppor/.gradle/caches/8.14.1/transforms/8de59f3a9ee765bf103d61bd35c1a99a/transformed/langchain4j-core-1.0.1-module.jar

This should not happen if deriveAutomaticModuleNamesFromFileNames is used, right?

Maybe it's an issue of extra-java-module-info plugin, because the .jar does not have any module-info.class:

MWE: JabRef/jabref-koppor#711

[koppor]

Maybe, this is related to gradlex-org/extra-java-module-info#106 (linked from JabRef/jabref#13258 (comment))

[jjohannes]

If anything, this would be an issue for https://github.com/gradlex-org/extra-java-module-info.

jpackage (and how it uses jlink) does not work with automatic modules as you can see on the error that is emitted directly by jlink.

The approach of this plugin, when combined with the other GradleX modules plugins, is that you provide a clean module setup, where each Jar is a real Java module. This is a different approach as the badass jlink plugin that merges Jars late in the process into one large artificial module.

To make everything a module, you can use extra-java-module-info, but the deriveAutomaticModuleNamesFromFileNames does not help you here. I consider that option something to use when you get started with moving existing projects to modules, but nothing to use permanently.

What you need to do is configure the plugin like this:

extraJavaModuleInfo {
    failOnAutomaticModules = true 
}

And then for each error you need to add a patch entry for a real module.

You can start with adding entries like this:

    module("org.eclipse.collections:eclipse-collections-api", "org.eclipse.collections.api")
    module("org.eclipse.collections:eclipse-collections", "org.eclipse.collections.impl")
    module("org.xerial.snappy:snappy-java", "org.xerial.snappy.java")

Then the plugin automatically creates a module-info.class that exports all packages and contains requires statements based on the repository metadata. In some cases that might not be enough, then you need to spell it out and add what is missing.

    module("com.google.jimfs:jimfs", "com.google.common.jimfs") {
        exportAllPackages() // in the "empty" entries above this is turned on by default
        requireAllDefinedDependencies() // in the "empty" entries above this is turned on by default
        requires("java.logging") // add a JDK core dependency (plugin can't know as this is not in the metadata)
    }

This can be tedious if you have a lot of legacy in the project. It is also an opportunity to clean up and remove things things if possible (if you want to see something positive in it 😄 ). The reward is that you will eventually have a much cleaner dependency structure.

As a "real world example", you can have a look here:
https://github.com/hiero-ledger/hiero-gradle-conventions/blob/main/src/main/kotlin/org.hiero.gradle.base.jpms-modules.gradle.kts

The good thing with these lists is that you can then give feedback to all libraries in there and help to move the whole ecosystem to a state where eventually the extra-java-module-info. is no longer needed.

[koppor]

Then the plugin automatically creates a module-info.class

Is it the plugin or is it me/us using the plugin which generates multiple (!) jar files?

Each run generates three of them...

[koppor]

"Highlight"

ERROR: Unmapping is not supported.: java.lang.reflect.InaccessibleObjectException:
Unable to make public jdk.internal.ref.Cleaner java.nio.DirectByteBuffer.cleaner() accessible:
module java.base does not "opens java.nio" to module org.apache.pdfbox.io

[koppor]

How to patch java.base?

    module("java.base", "java.base") {
        patchRealModule()
        // org.apache.pdfbox.io requires jdk.internal.ref.Cleaner (via java.nio.DirectByteBuffer.cleaner())
        // jabgui requires at least "javafx.collections"
        exportAllPackages()
    }

[koppor]

In IntelliJ, I got four different JARs to choose from for javafx.scene.Node

[koppor]

I think, we managed to patch all things. Although I do not remember how we fixed the PDFBox issue, it is solved.