search

jnr / jffi

Java Foreign Function Interface
Apache License 2.0
168 stars 78 forks source link

Add Automatic-Module-Name to MANIFEST.MF #67

Closed kamenik closed 3 years ago

kamenik commented 5 years ago

Could you please add Automatic-Module-Name row to MANIFEST.MF? Problem is jffi...jar and jffi...native.jar look like one module for java now.

headius commented 5 years ago

Does adding just to jffi jar solve this issue? I am unsure if we need it in the native jar, since that's not used to load any JVM classes.

PR?

4s1 commented 5 years ago

I think I probably ran into the same issue as kamenik, so I might be able to help out to solve the issue.

My symptom was the given root cause exception whenever I tried to access dbus, which was caused by this dependency. The error depends on the order, the jars are specified in java's --module-path argument

Caused by: java.lang.UnsatisfiedLinkError: java.lang.UnsatisfiedLinkError: could not locate stub library in jar file.  Tried [jni/x86_64-Linux/libjffi-1.2.so, /jni/x86_64-Linux/libjffi-1.2.so]
        at jffi@1.2.17/com.kenai.jffi.internal.StubLoader.getStubLibraryStream(StubLoader.java:412)

or 

Caused by: java.lang.NoClassDefFoundError: com/kenai/jffi/Type
        at jnr.ffi@2.1.9/jnr.ffi.provider.jffi.NativeRuntime.jafflType(NativeRuntime.java:193)

Background: I created an modularized application (with java 12), which depends on hypfvieh/dbus-java-3.2.0-SNAPSHOT, which depends on jffi1.2.17. When I start my application, java (jdk9+) tries to auto name each non modularized jar in module-path (by convention of https://docs.oracle.com/javase/9/docs/api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...- into module.name@version) So jffi-1.2.7.jar end up as jffi@1.2.17 and jffi-1.2.17-native.jar as jffi@1.2.17-native. The latter seems to get hidden as there is already a jffi module bound (can be traced when java is started with --show-module-resolution)

So I renamed jffi-1.2.17-native.jar to jffi-native-1.2.17.jar, just to get caught by an other exception

Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for /home/andre/.gradle/caches/modules-2/files-2.1/com.github.jnr/jffi/1.2.17/19335d57d54d54680bdf5aa2fe92cd41f5cd29ee/jffi-native-1.2.17.jar
Caused by: java.lang.IllegalArgumentException: jffi.native: Invalid module name: 'native' is not a Java identifier

So native seems to be preserved in some way and is not allowed to be used on module name.

Long story short, there are two possible fixes to get jffi working with modularized jdk9+ applications (beside the obvious modularization part)

  1. rename the native jar to be distinguishable from jffi jar by jdk9+'s ModuleFinder (e.g. jffi-syslibs-1.2.17.jar)
  2. add Automatic-Module-Nameto META-INF/MANIFEST.MF (e.g. Automatic-Module-Name: jffi.syslibs)
headius commented 5 years ago

Will do this very soon as part of modularizing JRuby!

headius commented 5 years ago

Oh, if you have a PR that gets us started here, that would be great. I'm traveling so my work hours will be a bit odd.

headius commented 3 years ago

Somehow I did not remember this bug when doing the recent module updates. Looks like @melowe has it in hand in #91

headius commented 3 years ago

Ok, so we did part of this in 1.3.0 by adding an automatic module name, but we did not foresee the issue of having both the main and native jar files using the same module name. I will commit a change based on #67 that provides a different automatic module name for the two jars.

headius commented 3 years ago

This will be fixed in 1.3.1 to be released soon.

headius commented 3 years ago

1.3.1 is released.