Manipulating ShortBuffer, endianess issues

[Deren]

I get some weird behaviour when I use the NDK for manipulating arrays.
I've got a ShortBuffer in my Java code which I pass to a JNI function.
It'll get the address using GetDirectBufferAddress, and set the first
element of the array to 1. When I get back to my Java code, if I print
the first element of the ShortBuffer, it says 256. On the other hand,
if I set the first element to 256, Java will print 1. How can this be?
It's almost like the C code uses little endian and Dalvik big endian
(or reversed). What is the problem?

[Jack Palevich]

It's an annoying feature of java.nio.Buffer objects that their default
byte order is big endian. (I think the theory is that big endian is
"network byte order". Try calling
buffer.order(ByteOrder.nativeOrder()) on you buffer, and then Java
will interpret the multibyte values the same way your native code
does.

[Deren]

Works like a charm :) Thank you!

[Pawel]

Hi,

I wouldn't call this annoying, but rather a reasonable Java[Dalvik?]
feature. Java was concieved as WORA(*), and though WORA is yet to
actually work that well, consistency of expectations of the byte order
across architectures is somewhat of a nice thing.

Thanks,
Pawel

* Write Once, Run Anywhere

--
Struggled to send from my iPhone

On Nov 14, 2009, at 4:02 AM, Jack Palevich <jack.p...@gmail.com>
wrote:

> --
>
> You received this message because you are subscribed to the Google
> Groups "android-ndk" group.
> To post to this group, send email to andro...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-ndk?hl=
> .
>
>

[fadden]

On Nov 14, 9:01 am, Pawel <pawel.vese...@gmail.com> wrote:
> I wouldn't call this annoying, but rather a reasonable Java[Dalvik?]  
> feature. Java was concieved as WORA(*), and though WORA is yet to  
> actually work that well, consistency of expectations of the byte order  
> across architectures is somewhat of a nice thing.

The annoying part is that they chose the wrong order. :-)