[vector] ByteBuffer byte ordering

[John Rose]

On Apr 13, 2018, at 2:09 PM, Lupusoru, Razvan A <razvan.a.lupusoru at intel.com> wrote:
> 
> I agree - the correct code actually should have preserved byte order for all API methods that actually take in ByteBuffer argument.
> Here is updated patch:http://cr.openjdk.java.net/~rlupusoru/panama/byteorder_01/byteorder_01.patch <http://cr.openjdk.java.net/~rlupusoru/panama/byteorder_01/byteorder_01.patch>
>  
> Namely, the fixed version does the following things:
> -          For byte arrays, since internally it uses byte buffer, it uses native ordering
> -          For methods accepting ByteBuffer, they need to maintain ordering.
> o   For case where ByteBuffer is duplicated (namely the version taking ByteBuffer + index), the order must be overridden since duplication of ByteBuffer does not preserve original ordering but updates it to be BIG_ENDIAN.
>  
> Let me know what you think now! Thanks for catching this error.

I think you caught that!  And I agree it's a good one.  I was more
concerned with the byte order on the internally created ones, but
of course (on second thought) we can specify what we want for
those.  Although it would be in some way cleaner to allow the
user to control byte ordering for rebracketing.  (Is that your
concern, Paul?)  Maybe the right answer is to allow an optional
argument (at some point) to rebracketing which specifies
input and/or output byte orders.  Relying on native byte order
implicitly is a design smell in Java APIs.

In your new javadoc you seem to have dropped " / Byte.SIZE"
after "v.bitSize()" even though it will be significant in the new text.

— John