Define a resize method on each primitive array type PrimT,
as if by this code:
    PrimT[] cloneRange(int from, int to) {
      int newLength = to - from;
      PrimT[] newThis = new PrimT[newLength];
      System.arraycopy(this, from, newThis, 0,
                       Math.min(length-from, newLength));
      return newThis;
    }

In addition, define the corresponding covariant-returning method on
Object[]:
    Object[] cloneRange(int from, int to) {
      int newLength = to - from;
      Object[] newThis = java.lang.reflect.Array.newInstance(
                             getClass().getComponentType(), newLength );
      System.arraycopy(this, from, newThis, 0,
                       Math.min(length-from, newLength));
      return newThis;
    }


In a recent project of 10K lines of Java, out of about 120 new array
operations, 9 were immediately followed by an arraycopy which could
have been expressed by the methods above. (This code used Collections
heavily, and would have used Collection-based idioms for these 120
array allocations, if possible. Most of the arraycopy calls were on
primitive arrays.)

This code pattern occurs wherever people are collecting
variable-count data into arrays, and can not or will not use Collection types.
(Note that collections do not work well with primitive types.)

This code pattern appears in performance-critical parts of the SDK,
such as string concatenation and collection building.

In general, many arrays in Java applications cannot be sized accurately
before they are filled. This implies a resizing operation, which currently
must use System.arraycopy which is weakly type-checked (the order of arguments
is notoriously difficult to remember). Moreover, if the initial allocation
of the array is generous enough, the System.arraycopy call might be executed
infrequently enough to make testing haphazard--perhaps big-enough arrays
will only occur in production use, opening up the prospect of a post-release
bug!

The bottom line is that writing the new/arraycopy idiom is error prone.
It also hides optimization opportunities from the compiler.

The above method covers both subrange extraction and resizing, in order
to minimize the number of new methods. It has no range check on the second
argument. If this is a problem, the method could be split into cloneRange
(range checking both arguments) and resize (no range check, but first argument
is omitted and is taken to be zero).

This proposal puts the method on array types, because of the great frequency
of the operation. A more conservative approach would put the methods on
java.util.Arrays, following the pattern of sort, binarySearch, etc.