This issue is related to Issue #209 (open) & #142 (closed).

I am creating this issue and pushing it in the stack so that I can get on with
what I set out to do: implement java.util.ArrayDeque so I could make a scalanative.regex
fix.. This issue & its fix are not impossible but are bigger than a breadbox.

I encountered this issue in the existing j.u.ArrayList.scala but it is simpler & clearer to discuss it
in the context of j.l.System.arraycopy.

This is really a specialization & refresh of the 3 year old Issue #209.

Presenting problem

The basic issue is that j.l.System.arraycopy and SN
scalanative.runtime.Array.copy() are defined to have slightly, but critically,
different behavior. This was discussed in issue #142 and the scala behavior
explicitly chosen for Array.copy().

Currently System.arraycopy() directly delegates to array.copy, so the two
have the same behavior, which is broken for the former.

I encountered this breakage in the ArrayListSuite where it tests copying
from one array to a second, where the second is not a the same class
or a super class of the former. Array.copy() follows the Scala behavior
and succeeds. System.arraycopy() is defined in Java 8 as throwing
ArrayStoreException (There is a large paragraph describing this
expected behavior, so the specification is intentional).

And that is not all folks!

A close code review of System.arraycopy() reveals other difficulties.
I am not sure if the "item by item" copy is description is really a requirement
or if the current, efficient, memmove implementation after a isAssignable()
check can continue to work.

The Kicker

Making the obvious fix to System.arraycopy() breaks the remote test runner!
No one can hear you scream in the middle of a hurricane....

I tested that that code fragment as a private def in a debug test Suite, so I
believe it to be good.

Desire to make progress on my main effort before I forget what I was doing has
kept from searching the sources for testing sources for usages of System.arraycopy.
It appears that some usage if failing with the new ArrayStoreException because
it is expecting the present scala behavior: not respecting class relationships.
The remote test runner then does it usual "silently dying in the night" routine and
never connects back.