I do not know which JVMs implement / do not implement direct ByteBuffers. But in a sense, this is not particularly relevant ... because it is always possible that some vendor will come out with a new JVM that changes the equation, supporting / not supporting direct ByteBuffers.
Should the JNI library always encode managed ByteBuffers and discard direct ByteBuffers as an optimization?
It depends on your purpose.
If your goal is maximum portability, then your JNI code should not assume that direct ByteBuffers are available.
If your goal is maximum performance, then your code may assume that direct ByteBuffers will always be available (and will break if it is not). In addition, you can have two different JNI libraries (or conditionally compiled versions of the same library) that the Java side chooses between them at runtime depending on the platform support for direct ByteBuffers.
But it all seems a bit disconnected from reality. Going down the JNI route, you implicitly accept the path of intolerance. You already have to deal with native libraries, which (at least) should be recompiled for different JVMs and different target platforms. And I would think that testing on all supported platforms is important.
In general, do not expect significant reductions for multi-platform support for your JNI code.
source share