United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4655503 need a resize method to go with clone on all array types
JDK-4655503 : need a resize method to go with clone on all array types

Details
Type:
Enhancement
Submit Date:
2002-03-20
Status:
Resolved
Updated Date:
2005-11-21
Project Name:
JDK
Resolved Date:
2005-06-25
Component:
core-libs
OS:
solaris_8,generic
Sub-Component:
java.util
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
5.0,6
Fixed Versions:

Related Reports
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

Description
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.

                                    

Comments
EVALUATION

  I believe this would be a nice addition to java.util.Arrays.  It is closely related to 4619338.

###@###.### 2002-04-14
                                     
2002-04-14
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mustang


                                     
2004-09-08



Hardware and Software, Engineered to Work Together