JVM: Could not find jna-5.17.0-jpms.jar

[Ribesg]

In a KMP project with Android, JVM and iOS targets, I added io.github.vinceglb:filekit-dialogs-compose version 0.11.0 as a commonMain dependency. It works on Android, but when I try to run the JVM target (named "desktop") I got this strange error:

➜ ./gradlew desktopRun

> Task :desktopRun FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':desktopRun'.
> Could not resolve all files for configuration ':desktopRuntimeClasspath'.
   > Could not find jna-5.17.0-jpms.jar (net.java.dev.jna:jna:5.17.0).
     Searched in the following locations:
         https://repo.maven.apache.org/maven2/net/java/dev/jna/jna/5.17.0/jna-5.17.0-jpms.jar

./gradlew runDistributable fails with the same error on createDistributable. I'm not sure why it's looking for a jar that doesn't exist and that never existed.

[Ribesg]

After some trial and error, this is the best workaround I found. I added this at the end of my build.gradle.kts file:

// TODO Workaround https://github.com/vinceglb/FileKit/issues/385
configurations.matching { it.name.startsWith("desktop") }.all {
    resolutionStrategy.eachDependency {
        if (requested.group == "net.java.dev.jna" && requested.name == "jna") {
            artifactSelection {
                selectArtifact("jar", null, null)
            }
        }
    }
}

Please note that my JVM target is declared as jvm("desktop"), which means the failing configurations names start with "desktop" in my case. You should use .startsWith("jvm") is you went with the default name. Getting rid of the .matching { … } block entirely should probably not cause any issue, I think.

[vinceglb]

Hi @Ribesg! Thanks for creating this issue.

Could it be the version of Java you are using? Honestly, I'm not sure what is causing that error 😕

[Ribesg]

6 months later and it still doesn't work if I comment my workaround above:

Execution failed for task ':desktopRun'.
> Could not resolve all files for configuration ':desktopRuntimeClasspath'.
   > Could not find jna-5.18.1-jpms.jar (net.java.dev.jna:jna:5.18.1).
     Searched in the following locations:
         https://repo.maven.apache.org/maven2/net/java/dev/jna/jna/5.18.1/jna-5.18.1-jpms.jar

I'm not really able to spend a lot of time investigating this issue as there is a workaround, but during that time I updated Java, Gradle, and other versions regularly. I honestly don't know anything about JPMS.

[donard-commedagh]

The format of the jar filename is incorrect - the version is in the wrong place:

https://repo1.maven.org/maven2/net/java/dev/jna/jna-jpms/5.17.0/jna-jpms-5.17.0.jar
https://repo1.maven.org/maven2/net/java/dev/jna/jna-jpms/5.18.1/jna-jpms-5.18.1.jar

[muriloonunes]

Also facing this issue as of July, it still tries to find this jna artifact:

org.gradle.internal.resolve.ArtifactNotFoundException: Could not find jna-5.19.1-jpms.jar (net.java.dev.jna:jna:5.19.1).
Searched in the following locations:
    https://repo.maven.apache.org/maven2/net/java/dev/jna/jna/5.19.1/jna-5.19.1-jpms.jar

Adding

configurations.configureEach {
    resolutionStrategy.eachDependency {
        if (requested.group == "net.java.dev.jna" && requested.name == "jna") {
            artifactSelection {
                selectArtifact("jar", null, null)
            }
        }
    }
}

to the end of my desktopApp/build.gradle.kts , where the dependency was declared, fixed it.

[vinceglb]

Thanks for the insight @muriloonunes. I will take a look

[vinceglb]

I was able to reproduce the exact error. It happens when another dependency requests the old net.java.dev.jna:jna:<version>:jpms artifact. FileKit then upgrades JNA to a newer version, but Gradle keeps the old jpms classifier and searches for a file that no longer exists.

You can identify the dependency with:

./gradlew dependencyInsight \
  --configuration desktopRuntimeClasspath \
  --dependency net.java.dev.jna:jna

Once identified, the preferred fix is to exclude its outdated JNA dependency:

implementation("group:problematic-library:version") {
    exclude(group = "net.java.dev.jna", module = "jna")
}

A known example is de.jangassen:jfa:1.2.0, which requests JNA using the old jpms classifier.

Your current artifactSelection workaround is also valid for a non-modular Compose Desktop application.

[muriloonunes]

Thanks for your help @vinceglb! The command you shared revealed that in my case the problematic library was com.github.Dansoftowner:jSystemThemeDetector:3.9.1 which was last updated two years ago, explaining why it was requesting an outdated version of JNA.

Thanks!