release notes for Java NIO(Java 1.4+版)声明支持直接ByteBuffers是一项可选功能。我很好奇哪些JVM供应商/口味不支持它? JNI库是否应该为受管理的ByteBuffers编写代码,并将直接的ByteBuffers作为优化来使用?哪些JVM不支持直接java.nio.ByteBuffer?
谢谢
release notes for Java NIO(Java 1.4+版)声明支持直接ByteBuffers是一项可选功能。我很好奇哪些JVM供应商/口味不支持它? JNI库是否应该为受管理的ByteBuffers编写代码,并将直接的ByteBuffers作为优化来使用?哪些JVM不支持直接java.nio.ByteBuffer?
谢谢
我不知道哪些JVM实现/不实现直接的ByteBuffers。但从某种意义上说,它并不特别相关......因为有些厂商总是有可能推出一款新的JVM,通过支持/不支持直接的ByteBuffers来改变等式。
JNI库是否应该总是为托管的ByteBuffers编写代码并将直接的ByteBuffers作为优化进行归档?
这取决于你的目标。
如果你的目标是最大的可移植性,那么你的JNI代码不应假定直接字节缓冲区是可用的。
如果您的目标是为了获得最佳性能,那么您的代码可能会假设直接的ByteBuffers将始终可用(如果不是,则会中断)。或者,您可以有两个不同的JNI库(或同一个库的条件编译变体),以便Java在运行时根据平台对直接ByteBuffers的支持情况进行选择。
但是,这一切似乎都与现实脱节。通过沿着JNI路线走下去,你就隐含地走上了不可移植的路径。您必须处理(至少)必须针对不同JVM和不同目标平台重新编译的本机库。我曾认为在所有支持的平台上进行测试都非常重要。
总之,不要指望任何重要的快捷方式可以为您的JNI代码提供多平台支持。