Extend and update getByteBuffer method about jcuda HOT 4 CLOSED

As proposed in https://forum.byte-welt.net/t/pointer-buffer-should-have-byteorder-little-endian/19508/3 , the implementation could be thread-safe and safe regarding the offsets by implementing it as

ByteBuffer byteBuffer = ((ByteBuffer)buffer).slice();
byteBuffer.limit(Math.toIntExact(byteOffset + byteSize));
byteBuffer.position(Math.toIntExact(byteOffset));

from jcuda.

It is probably worth considering that Nvidia (and AMD) GPUs are LITTLE_ENDIAN, so IMHO native should be the default.

from jcuda.

Using the nativeOrder() certainly makes sense. In fact, I occasionally stumbled over the (nowadays somewhat unusual) BIG_ENDIAN being the default, and wondered why they did this...

_{(This was an attempt to blame the Sun/Oracle people ;-) )}

It would have made even more sense to do this right in the beginning, when the method was implemented. As mentioned above (and in the forum thread ), changing this now might be incompatible.

But although I'm always hesitant do do changes like this, here, it may be justified: Most users probably already did set the byte order manually. And they did this (or should have done this) because until now, the byte order of the returned buffer was not specified.

The advantage of specifying it now to be the nativeOrder() seems to outweigh the slight possibility of an incompatibiliy, especially when it's pointed out in the change log.

from jcuda.

BIG_ENDIAN is the default probably because it is the "network" byte order used by many protocols such as TCP/IP.

File I/O defaults to whatever is the system's code page, while NIO standardizes on BIG_ENDIAN. The JDK guys made the wrong choice both times :)

from jcuda.