2011-03-27 17 views
3

での可能性の重複:私のJavaアプリケーションで
Java : switching between dll depends on system architecture (32/64)読み込んで32ビットまたは64ビットJNIライブラリのJava

は、私が32ビットと64ビットのために利用可能であるJNIライブラリを必要としています。私はアプリケーションの2つの異なるバージョンを出荷する必要はないので、両方のライブラリでアプリケーションを出荷する必要があり、アプリケーションはロードするライブラリ(foobar32.soまたはfoobar64.so)を決定する必要があります。それ、どうやったら出来るの?

私は最初のものを読み込もうとしていましたが、例外がスローされた場合は2番目のものを読み込みますが、これは醜いと思います。

アプリケーションを実行するために32ビットのJavaまたは64ビットのJavaが使用されているかどうかを確認するためのシステムプロパティがありますか?私はいくつかのos.archプロパティがあることを知っていますが、戻り値はthis answerによればかなり予測できないようです。

32ビットまたは64ビットのJNIライブラリをロードするかどうかをアプリケーションに決定させる最も良い方法は何ですか?

+0

アプリケーションをどのようにバンドルしていますか? OSGiでは、OSアーキテクチャに応じて、特定のバンドルまたはバンドル・フラグメントのみをロードできます。これは、プラットフォーム固有の機能がどのように提供されるかです。 OSGiの使用を検討できますか? – katsharp

+0

あなたの主な関心事は、OSとは異なり実行可能なものです:64ビットOS上で32ビット実行可能ファイルを実行できますが、それでも32ビットであり、必要なライブラリは64ビットではない32ビットです。仮に32ビットOSでは、64ビットライブラリが必要です。これはprzemelekが説明しようとするものです。 'os.arch'はそれが存在する限り、事実上何かのために十分に良いでしょう、私の答えは、Unsafeがそこにあるかもしれないが、いくつかのシステムプロパティがそうでないケースをターゲットにしていました。 – bestsss

答えて

5

なぜ予測できないのですか?あなたはそれが32ビットシステムであるかどうかを検出したいだけで、この場合は常にx86プロセッサ(もちろんx86プロセッサの場合)になります。他のすべては64ビットを意味します。

問題は、コードがPPCまたは他の非x86プロセッサでも実行される可能性があることがわかった場合に開始されます。しかし、この場合、例外駆動型のフロー制御で醜いハックを使用し、そのような状況を "検出"するためにtry {} catch()を使用することができます。

IMHO os.archが最適なソリューションになります。

+0

@przemelek - 'os.arch'は、実行しているシステムではなく、jarのコンパイルに使用するシステムのプロパティを返すので、信頼できません。(私の答えのリンクを参照してください) – MByD

+1

@MByD:いいえ、システムプロパティ' os.arch' ---すべてのJavaシステムのプロパティ---はコンパイル時の概念ではなく、実行時の概念です。したがって、ランタイムアーキテクチャを返します。 – jmg

+0

@ jmg。私が間違えました。 'os.arch'からの戻り値はランタイム値ですが、実際のアーキテクチャではなくJREのビット数に依存します。したがって、64ビットWindowsマシンで32ビットJREを実行している場合は、' x86'を結果。この記事をご覧ください:http://mark.koli.ch/2009/10/javas-osarch-system-property-is-the-bitness-of-the-jre-not-the-operating-system.html – MByD

0

Unsafe.addressSize();

報告{@link #putAddress}介して格納されているように、ネイティブポインタのバイト単位のサイズ、。この値は4または8のいずれかになります。

ここから取得できます。

+0

もしあなたが_sun.misc.Unsafe_を意味するのであれば、これは他のJava実装がそれを提供しないので使いにくいものです。 – kayahr

+0

@kayahr、UnsafeなしのJavaバージョンで動作するネイティブライブラリを持つ確率はほとんどありません。 – bestsss

関連する問題