0

私はEclipseプラグインを構築しています（Notesプラグインですが、最終的にはEclipseプラグインです）。私のプラグインが依存しているプラ​​グインの1つは、ネイティブdllをロードする必要があります。

問題は、そのようなdllがディスクのどこにあるかに応じて失敗することです。特定のしきい値よりも長い場合、以下のエラーが発生します

java.lang.UnsatisfiedLinkError：nlsxbe（ファイル名または拡張子が長すぎます。）at java.lang.ClassLoader.loadLibraryWithPath（ClassLoader.java:952）at java.lang.ClassLoader.loadLibraryWithClassLoader（ClassLoader.java:921）atjava。 lang.System.loadLibrary（System.java:452）at lotus.domino.NotesThread.load（Unknown Source）at lotus.domino.NotesThread.checkLoaded（Unknown Source）at lotus.domino.NotesThread.sinitThread（Unknown Source）at com .atempo.adam.lotus.plugin.views.TopicView.createPartControl（TopicView.java:609）

パスをPathenvvarに追加し、dllを登録しました。私の環境は、Ms vista profesional、java1.5、eclipse3.4（およびロータス8）です。

誰か手がかりがありますか？

よろしくお願いします。

4

3 に答える 3

1

これは、WindowsのMAX_PATH制限の症状の1つです。それについてのKBノート（たとえば320081）と、Googleを使用して簡単に見つけることができるこれらのファイルに対処するための手動の方法に関するいくつかの議論があります。

問題は、Windowsには、さまざまなシステムおよびコマンドレベルの呼び出しで使用される完全なファイルパスの長さに制限があることです。ユーザーコミュニティから多くの議論がありましたが（そしてMicrosoft KBで試すべきいくつかの斬新なことさえ）、それらはすべて、公正な手段または反則によって問題のファイルのファイルパスを短縮することになります。

MicrosoftのUnicodeAPIが（最大）32kバイトのファイルパスを許可していることを示す兆候がありますが、これが正しいかどうかはわかりません。ただし、既存のプログラムの多くはこれらのAPIを使用していないため、この制限を超えています。（Windows APIがUTF16（またはUCS2）を使用する可能性もあります。その場合、これは16k文字のみを意味します。これについて誰か知っていますか？）

このシステムでは、さまざまな方法で「到達不能」なファイルパスを作成できます。1つは、ナビゲーションによってパスにステップを段階的に作成することです。もう1つは、共有をマウントすることです。システム機能とユーティリティは、この制限を超える操作のために、内部的に完全なファイルパスに依存する場合があります。

この基本的な愚かな制限がWindowsシステムコードから削除されない限り、唯一の手段はファイルを移動したり名前を変更したりすることです…</ p>

…またはUnixを実行します。

于 2009-06-24T10:36:46.427 に答える
1

同様の問題があり、ファイルが長いパスにないことを確認する必要がありました。

組み込みの Windows プログラムの一部を含め、長いパスに問題があると思われるプログラムが多数あります。

この DLL が存在する場所を制御できますか?

于 2009-06-02T16:58:35.720 に答える