[vector] Add non-masked Vector. intoByteArray accepting a byte order

[Paul Sandoz]

Ah, I should have guessed the intent, what threw me off the scent was the odd (3) number, compared to intoByteBuffer (2):

  public abstract void intoByteBuffer(ByteBuffer bb, int offset, ByteOrder bo);
  public abstract void intoByteBuffer(ByteBuffer bb, int offset, ByteOrder bo, VectorMask<E> m);

And, further, [EType]Vector.fromByteArray has all four variants.

Perhaps rather than filling out we need to slim down. where ByteOrder is a required parameter, then that fits with the pattern of non-mask and mask variants of many other methods:

  public abstract void intoByteArray(byte[] a, int offset, ByteOrder bo);
  public abstract void intoByteArray(byte[] a, int offset, ByteOrder bo, VectorMask<E> m);

And, we do the same for [EType]Vector.fromByteArray.

When we add MemorySegment accepting methods we can follow the same pattern.

?

Paul.

> On May 5, 2020, at 6:48 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> FTR, I intentionally left that out, because if a programmer
> wants to specify a byte order, it’s a pretty simple matter to
> specify a mask also.  You simply say:
> 
>  Vector data = …;
>  data.intoByteArray(a, 0, bo, data.maskAll(true));
> 
> The presence of Vector::maskAll (like the presence of Vector::broadcast)
> reduces the pressure to multiply out all the masked and unmasked variants
> (or all broadcast-scalar and vector-lane-wise variants) of many API points.
> 
> On May 5, 2020, at 5:14 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> 
>> Hi
>> 
>> Please review the following that adds a missing non-masked Vector. intoByteArray accepting a byte order:
>> 
>> http://cr.openjdk.java.net/~psandoz/panama/vector-intoByteArray-with-byte-order/webrev/ <http://cr.openjdk.java.net/~psandoz/panama/vector-intoByteArray-with-byte-order/webrev/>
>> 
>> Tests have also been expanded to operate over the byte order values.
>> 
>> Paul.
>