JDK-8218931 : (bf) NewDirectByteBuffer always has order ByteOrder.BIG_ENDIAN
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P5
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 13
  • Submitted: 2019-02-13
  • Updated: 2019-03-15
  • Resolved: 2019-02-21
Related Reports
CSR :  

Change NewDirectByteBuffer JNI specification to match that of java.nio.ByteBuffer.allocateDirect() and its longstanding behavior.


NewDirectByteBuffer does not specify that the direct ByteBuffer object it constructs has byte order java.nio.ByteOrder.BIG_ENDIAN.


Update the NewDirectByteBuffer JNI specification verbiage.

--- a/closed/src/java.se/share/specs/jni/functions.md
+++ b/closed/src/java.se/share/specs/jni/functions.md
@@ -3610,10 +3610,12 @@
 `jobject NewDirectByteBuffer(JNIEnv* env, void* address, jlong capacity);`
 Allocates and returns a direct `java.nio.ByteBuffer` referring to the block of
 memory starting at the memory address `address` and extending `capacity` bytes.
+The byte order of the returned buffer is always big-endian (high byte first; 


Moving to Approved. Please consider adding a release note and possibly contacted the J9 team to give them a heads up.

I hadn't realized that the VM implementation of NewDirectByteBuffer simply allocated a library level Java object and so was oblivious to any endian issues. So this should really just be about aligning the JNI documentation of this method with the library level implementation. It seems less likely that another implementation of JNI might do this differently.

The code for this is java.nio, not the VM but it wouldn't do any harm if the IBM folks could comment.

Unknown what other J9 or other VMs do but if they are doing the upcall like HotSpot then it will be the implementation in the libraries that determines the ordering.