java.lang.unsatisfiedlinkerror:,java.lang.UnsatisfiedLinkError-本机方法问题

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...

解决方案

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)

C:>dumpbin /headers yourd.dll

Dump of file yourd.dll

PE signature found

File Type: DLL

FILE HEADER VALUES

8664 machine (x64)

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 ).