gs1-syntax-engine icon indicating copy to clipboard operation
gs1-syntax-engine copied to clipboard

Instanciating GS1Encoder from gs1encoders.dll raises an UnsatisfiedLinkError: 'long org.gs1.gs1encoders.GS1Encoder.gs1encoderInitJNI()'

Open nlenew opened this issue 6 months ago • 1 comments

Could you please help me with this issue ?

I am running the Example code on Windows using the gs1encoders DLL.

I have added the directory containing the DLL to the java.library.path (using VM option -Djava.library.path) but when I try to instanciate the GS1Encoder, this exception is raised :

java.lang.UnsatisfiedLinkError: 'long org.gs1.gs1encoders.GS1Encoder.gs1encoderInitJNI()'

I am quite sure the DLL is found as I have ran my code on debug mode and the ClassLoader has well loaded the DLL.

Simple sample to reproduce :

public static void main(String[] args) { GS1Encoder gs1encoder = new GS1Encoder(); } P.S. : it is working well with the libgs1encoders.so on Linux

Thanks for your help.

nlenew avatar May 23 '25 14:05 nlenew

I suspect that you might be referencing the static library itself, rather than a JNI wrapper DLL.

On Linux, the build.xml generates the wrapper DLL by statically linking the native library DLL.

The build step isn't defined yet for Windows, but if you successfully attempt it with MSVC based on the existing GCC command and let me know what works then I'll add the conditional logic.

Otherwise I'll take a look, probably next week.

terryburton avatar May 23 '25 18:05 terryburton

What I would like to do is not to use the Java wrapper itself but load the libgs1encoders.jar and the gs1encoders.dll based on the build I have done with MSVC. I am packaging a fatjar/libs containing the libgs1encoders.jar and the gs1encoders.dll and even if the DLL is loaded, then the error is raised : java.lang.UnsatisfiedLinkError: 'long org.gs1.gs1encoders.GS1Encoder.gs1encoderInitJNI() Maybe I am doing it wrong and it needs to be always done using the java wrapper build process.

Please, let me know.

nlenew avatar May 26 '25 09:05 nlenew

If you are using only gs1encoders.dll then you are missing the JNI wrapper functions, as the link error states. It doesn't matter what build tooling you use, you must create a library that contains the JNI wrappers, in addition to having access to the encoder library functions.

This is the same on Linux, but the JNI wrapper library's name clashes with the C library name, so perhaps wasn't clear that they are not in fact the same thing. (In fact on Linux, the JNI library statically includes the main library, so only one library file is necessary. But that's a bit more irksome on Windows.)

I have updated the build.xml to add Windows support, and changed the name of the JNI wrapper library to "gs1encodersjni" to disambiguate it from the main library.

The following steps worked for me:

  • Build the gs1encoders.dll by runnig the gs1encoders target of the solution.
  • Run ant to build the JNI wrapper library, which uses the assets build in the previous step.
  • Manually place the main library DLL into the same directory as the JNI library (to avoid having to update the library search path).
  • Run ant test, which builds the Example application that uses the JNI wrapper library. This works.

Based on what's there you should be able to adapt your existing MSVC-based process to build the gs1encodersjni.dll, which should load successfully via System.loadLibrary("gs1encodersjni"), provided that gs1encoders.dll is also in the path.

terryburton avatar May 26 '25 15:05 terryburton

CI now builds and tests the Java wrapper on Windows:

https://github.com/gs1/gs1-syntax-engine/blob/main/.github/workflows/gs1encoders.yml#L194-L218

terryburton avatar May 26 '25 21:05 terryburton

It works now, thanks a lot.

I still had to make some work around as my OS is x64.

Now I am following with attention this other issue Java wrapper: Create multi-architecture JAR distributed via Maven Central as it will be easier for application integration :).

nlenew avatar May 27 '25 10:05 nlenew

It works now, thanks a lot.

Good to hear.

Now I am following with attention this other issue Java wrapper: Create multi-architecture JAR distributed via Maven Central as it will be easier for application integration :).

Agreed. Getting a robust CD pipeline developed is a monumental task, and it a shame that the strategy won't work for Android apps.

But your expression of interest helps to justify the packaging effort.

terryburton avatar May 27 '25 10:05 terryburton