1

dll の使用に関して、Java (Eclipse) で問題が発生しています。これまでのところ、次の問題が発生しています。

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)

これが問題の解決に役立つかどうかはわかりませんが、このプロジェクトでも JADE を使用しています...

編集 (2014 年 4 月 28 日):

私が使用しようとしているdllはカスタムのものです（私が働いている会社の元従業員によって作成されました）。

この問題の興味深い点は、同様のタスクを実行する 2 つの Java プロジェクトがあることです。このプロジェクトの 1 つは完全に実行されますが、もう 1 つはUnsatisfiedLinkError.

binパスについて: ワークスペース フォルダーに含まれる dll 用の特定のフォルダーを作成しましたが、プロジェクト フォルダーsrc内bibsにはありません (つまり、、、、、などと同じフォルダーsettings)。このフォルダーの構成は、私が持っている両方のプロジェクトで同じです。また、System.out.println(System.getProperty("java.library.path")メソッドは既にテスト済みで、両方のケースで正しいパスが返されます。

編集 (2014 年 4 月 29 日):

エラーメッセージに関する追加情報を追加しました。問題は JADE の使用に関連している可能性があると考え始めています...

4

4 に答える 4

1

問題の特定に役立つ PD 手順を次に示します。

以下をプログラムに追加して、2 つのランタイム環境間のアーチ パスとロード パスの違いを識別します。パス/アーチの違いを調査します。

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

dumpbin.exe ユーティリティを使用して、読み込まれている DLL に必要な依存関係を特定できます。依存関係が存在することを確認してください。使用例:

C:> dumpbin /imports your.dll 

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

where.exe コマンドを使用して、依存関係の場所を見つけることができます。使用例:

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

表示される場合:

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

従属 DLL がパス上にない理由を調べてください。

dumpbin.exe コマンドを使用して、64 ビットと 32 ビットを確認できます。
例：

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

メイン/従属間の 32 ビットと 64 ビットの不一致を調査します。JVM が 32 ビットの場合、32 ビット DLL を使用する必要があります。JVM が 64 ビットの場合、64 ビット DLL を使用する必要があります。(64 ビット OS で 32 ビット JVM を実行しても問題ありませんが、JNI DLL は 32 ビットでなければなりません (DLL は OS ではなく JVM に一致します)。

于 2014-04-29T04:16:39.047 に答える
0

ここでのいくつかの回答とは対照的に、これはライブラリの読み込みの問題ではありません。スタック トレースを参照してください。例外で指定されたメソッドを見つけるのに問題があります。これは、実際の名前と予想される名前の不一致が原因です。よくある原因:

  • .h ファイルの生成に javah を使用しない
  • .h と .c/.cpp ファイルのメソッド署名が一致しません
  • .c または .cpp ファイルに .h ファイルを含めない
  • javah の実行後に Java クラスのパッケージまたは名前を変更する
  • javah の実行後にメソッド名または署名を変更する

最後の 2 つのいずれかを行う場合は、javah を再実行し、.c/.cpp ファイルを調整して、新しい .h ファイルの新しい署名に一致させる必要があります。

于 2014-04-30T21:46:01.500 に答える
-1

これは、ライブラリのバージョンの不一致またはビットの不一致が原因である可能性があります。64 ビット OS で作業している可能性があります。JAR ファイルの 64 ビット互換バージョンを使用してください。また、JARS 間のバージョンの不一致も確認してください。

于 2014-04-28T18:05:19.427 に答える
-1

ネイティブ ライブラリを使用すると、システムは環境変数と java.library.path の両方でそれをチェックします。システム プロパティが見つからない場合は、java.lang.UnsatisfiedLinkError がスローされます。system32 フォルダーが既にパスに存在するため、Windows は system32 から dll を選択します。このため、こちら側からのエラーの変更はほとんどありません。ネイティブ ライブラリは、Java コードをプラットフォームに依存させます。必要な dll の Java パスを確認してください。java.library.path を確認し、System.loadLibrary("library name") を使用してライブラリ (dll 拡張子なし) をロードしてみてください。この助けを願っています。:)

于 2014-04-28T18:21:39.557 に答える