64ビットOS上で32ビットOSランタイムの問題でコンパイルされたJava

32ビットマシンでコンパイルされ、64ビットマシンで実行されるJavaアプリケーションの実行に関する既知の問題はありますか？64ビットOS上で32ビットOSランタイムの問題でコンパイルされたJava

出典

2011-07-25 Paul

いいえ、あなたが何かばかげていない限り、 – Petesh

こんにちはPetesh、あなたは何か「愚かなこと」の意味をより具体的にすることはできますか？ – Paul

64ビット版のコンパイルではなく、32ビット版のコンパイルでは問題はありません。愚かなことは何かプラットフォーム固有のことです。 – Petesh

32ビットJDKによって生成されるバイトコードは、64ビットJDKによって生成されるバイトコードと同じです。 64ビットJVMでのみ発生する問題がある場合は、JVMにバグがあり、64ビットJDKを使用しても差がないためです。

出典

2011-07-25 08:32:44

これはアプリケーションによって異なりますが、通常の状況下では、x64マシンのx86マシンからコードを実行しても問題ありません。その逆もあります。

プレーンな古いJava（interopやネイティブライブラリへの呼び出しなし）を使用すると、生成されるバイトコードはマシンに依存せず、インストールされているJVM上で実行する必要があります。

出典

2011-07-25 08:36:58 Falanwe

ネイティブライブラリへの呼び出しはわずかです（5未満）。生成されたバイトコードが異なる場合、既知の問題はありますか？生成されたバイトコードがまだ実行されている限り、私は気にしません。それは私が再びライブラリを生成しなければならないということですか？ – Paul

ネイティブライブラリの呼び出しがある場合は、ターゲット環境用にこれらのライブラリを再度コンパイルする必要があります。 Javaで生成されたバイトコードも同じです。 – Falanwe

@Paulでは、互換性のないプラットフォームごとにライブラリをコンパイルする必要があります。 –

環境に固有の32ビットネイティブコードを明示的に呼び出さない限り、私は考えることはできません。

Windowsなどのオペレーティングシステムでは、WoW64を使用して32ビットアプリケーションを64ビットシステムで実行することができます。これは、下位互換性を可能にする規定です。ネイティブライブラリが32ビットのみに依存するか、または64ビットライブラリのみに依存する限り、すべてが良好です。 JVMはバイトコードをJITを使って適切なマシンコードに変換するので、心配はありません。

出典

2011-07-25 08:45:29

Javaの背後にあるアイデアは、プログラムのバイトコードバージョンがすべてのプラットフォームで同じであるということです。このため、Windowsマシンでコンパイルし、その結果のクラスとjarファイルをLinuxボックスで実行することができます。私は毎日そのようなクロスコンパイルを行います。

これには、JVMが32ビットまたは64ビットを使用するかどうかが含まれます。

ので、簡単な答えはノー、何の問題

ありませんである（より高度な答えはあなたにもDLLのように、あなたはJavaコードで持参非Javaネイティブコードを使用している場合ということですそれで、そのコードは再コンパイルする必要があります）

出典

2011-07-25 08:47:12

64ビットOS上で32ビットOSランタイムの問題でコンパイルされたJava

答えて

関連する問題