Java NIO (Java 1.4以降)のリリースノートには、直接ByteBufferのサポートはオプション機能であると記載されています。どのJVMベンダー/フレーバーがそれをサポートしていないのか知りたいですか?JNIライブラリは常にマネージドByteBufferをコーディングし、最適化として直接ByteBufferを委任する必要がありますか?
ありがとう
Java NIO (Java 1.4以降)のリリースノートには、直接ByteBufferのサポートはオプション機能であると記載されています。どのJVMベンダー/フレーバーがそれをサポートしていないのか知りたいですか?JNIライブラリは常にマネージドByteBufferをコーディングし、最適化として直接ByteBufferを委任する必要がありますか?
ありがとう
どの JVM が直接 ByteBuffers を実装しているか、実装していないかわかりません。しかし、ある意味では、それは特に関連性がありません...なぜなら、直接ByteBuffersをサポートする/サポートしないことで方程式を変える新しいJVMをベンダーが発表する可能性は常にあるからです。
JNI ライブラリは常に管理された ByteBuffers をコーディングし、最適化として直接 ByteBuffers を委譲する必要がありますか?
それはあなたの目標に依存します。
最大限の移植性が目的の場合は、JNI コードで直接 ByteBuffer が使用可能であると想定しないでください。
目標が最大のパフォーマンスである場合、コードは直接 ByteBuffers が常に利用可能であると想定できます (そうでない場合は壊れます)。または、2 つの異なる JNI ライブラリ (または同じライブラリの条件付きでコンパイルされたバリアント) を使用して、プラットフォームの直接 ByteBuffers のサポートに応じて、Java 側が実行時にどちらかを選択することもできます。
しかし、これはすべて現実から少し切り離されているようです。JNI ルートをたどると、暗黙のうちに非移植性の道をたどることになります。(少なくとも) 異なる JVM および異なるターゲット プラットフォーム用に再コンパイルする必要があるネイティブ ライブラリを既に処理する必要があります。そして、サポートされているすべてのプラットフォームでテストすることが不可欠だと思っていました。
要約すると、JNI コードのマルチプラットフォーム サポートに重要な近道があるとは期待しないでください。