Part 1 Proposal for JDK-8264594

[Maurizio Cimadamore]

On 27/04/2021 19:12, Maurizio Cimadamore wrote:
>> To expand on what I think you are proposing,  we would be adding to 
>> MemorySegment:
>>
>> public MemorySegment copyInto(byte[] dstArray, int dstStartIndex, 
>> dstElements) {} //assumes native order
>> public MemorySegment copyInto(byte[] dstArray, int dstStartIndex, 
>> dstElements, ByteOrder order) {}
>> ... 6 more pairs
>> public MemorySegment copyFrom(byte[] srcArray, int srcStartIndex, 
>> srcElements) {} //assumes native order
>> public MemorySegment copyFrom (byte[] srcArray, int srcStartIndex, 
>> srcElements, ByteOrder order) {}
>> --- 6 more pairs
>>
>> A total of 28 methods.
> These are a lot of methods, for sure. I wonder if we could merge some 
> of these a la System::arrayCopy - e.g. make the array parameter be 
> Object. If we do that, we only need 2/4 (depending on the overloads) ?

Another possibility is to exploit the existing toByteArray, toIntArray 
and friends.

E.g. keep using copyFrom overloads to copy stuff into the receiver 
segment, but use overloaded version of toByteArray to copy things out of 
the segment.

This would lead to:

```
MemorySegment srcSegment = ...
int[] targetArray = ...
//start here
srcSegment.asSlice(srcStart, length)
                    .toByteArray(targetArray, dstStart, length);

```

Note that Collection::toArray can also take an existing array and copy 
existing elements into it.

This would "split" the overloads between copyFrom and toXYZ array.

Another suggestion for the overload, is to maybe start without the 
ByteOrder-less overload. ByteOrder.nativeOrder() is just one native call 
away, after all.

This would give us 7 more copyFrom and 7 more toXYZArray - which IMHO 
looks like a good trade off.

Maurizio