java.lang.UnsatisfiedLinkError - Native method issue

Question

I am experiencing a problem in Java (Eclipse) regarding the usage of dlls. Until now, I am experiencing the following problem:

Uncaught Exception for agent SomeAgent 
java.lang.UnsatisfiedLinkError: SomePackage.SomeClass.SomeNativeMethod(II)Z
[...]
at jade.core.behaviours.Behaviour.actionWrapper(Behaviour.java:344)
at jade.core.Agent$ActiveLifeCycle.execute(Agent.java:1532)
at jade.core.Agent.run(Agent.java:1471)
at java.lang.Thread.run(Thread.java:745)

I don't know if this will help to figure out the problem, but I am also using JADE in this project...

EDIT (28/04/2014):

The dll which I am trying to use is a custom one (was created by an ex-employee from the company where I work).

The curious thing about this problem is that I have 2 java projects which perform similar tasks. One of this projects runs perfectly, while the other one is experiencing the UnsatisfiedLinkError .

About the paths: I've created a specific folder for the dlls which is contained in the workspace folder, but not inside the project folder (in other words, the same folder where bin , src , bibs , settings , etc. are). This folder's configuration is equal for the both projects I have. Also, I've already tested the System.out.println(System.getProperty("java.library.path") method and the right path is returned on both cases.

EDIT (29/04/2014):

Just added some additional information regarding the error messages. I am starting to think that the problem may be related to the JADE usage...

Answer 1

Here is a PD procedure that might help you identify the problem.

Add the following to your program to identify the differences in the arch and load paths between the two runtime environments. Investigate any differences in path/arch.

 System.out.println(System.getProperty("java.library.path"));
 System.out.println(System.getProperty("sun.arch.data.model"));

You can use the dumpbin.exe utility to identify the dependencies needed by the DLL that is being loaded. Make sure the dependencies exist. Example usage:

C:> dumpbin /imports your.dll 

Dump of file your.dll
File Type: DLL
  Section contains the following imports:
    **KERNEL32.dll**

You can use the where.exe command to find the location of the dependencies. Example usage:

C:>where KERNEL32.dll
    C:\Windows\System32\kernel32.dll

If you see:

C:>where KERNEL32.dll
    INFO: Could not find files for the given pattern(s)

Investigate why the dependent DLL is not on the path.

You can use the dumpbin.exe command to check 64bit vs 32bit.
Example:

C:>dumpbin /headers yourd.dll

 Dump of file yourd.dll
 PE signature found
 File Type: DLL
 FILE HEADER VALUES
         14C machine (x86)    <-- 32bit DLL

C:>dumpbin /headers yourd.dll

 Dump of file yourd.dll
 PE signature found
 File Type: DLL
 FILE HEADER VALUES
         8664 machine (x64)    <-- 64bit DLL

Investigate any 32bit vs 64bit mismatches between main/dependent. If your JVM is 32bit, you need to use 32bit DLLs. If your JVM is 64bit, you need to use 64bit DLLs. ( It is okay to run a 32bit JVM on a 64bit OS but the JNI DLLs must be 32bit ( DLLs match the JVM not the OS ).

Answer 2

Contrary to several answers here, this is not a library loading problem. See the stack trace. It's a problem locating the method named in the exception. This is caused by a mismatch between the actual and expected names. Popular causes:

• not using javah to generate the .h file
• method signature in .h and .c/.cpp file do not agree
• not including the .h file in the .c or .cpp file
• changing the package or name of the Java class after running javah
• changing the method name or signature after running javah

If you do either of the last two you must re-run javah and adjust the .c/.cpp file to agree with the new signature in the new .h file.

Answer 3

This might be due to version mismatch or bit mismatch of your library. You may be working on 64 bit OS, use 64 bit compatible versions of your JAR files. Also check for version mismatch between JARS.

Answer 4

When you use some native library your system will check it in both environment variable and java.library.path. system property if it does not found there then it will throw java.lang.UnsatisfiedLinkError. Windows pick dll form system32 because system32 folder already exists in the path so there is very less change of error form this side. Native libraries make java code platform dependent. Check your java path for the required dll. Check your java.library.path and try to load your library(without dll extension) by using System.loadLibrary("library name"). Hope this help. :)