Java List T[] toArray(T[] a) implementation

Question

I was just looking at the method defined in the List interface: <T> T[] toArray(T[] a) , and I have a question. Why is it generic? Because of that fact, method is not complete type-safe. The following code fragment compiles but causes ArrayStoreException:

List<Integer> list = new ArrayList<Integer>();
list.add(1);
list.add(2);

String[] stringArray = list.toArray(new String[]{});

It seems to me if toArray was not generic and took List type parameter, it would be better.

I have written toy example and it is ok witout generic:

package test;

import java.util.Arrays;

public class TestGenerics<E> {
    private Object[] elementData = new Object[10];
private int size = 0;

    public void add(E e) {
    elementData[size++] = e;
}

@SuppressWarnings("unchecked")
    //I took this code from ArrayList but it is not generic
public E[] toArray(E[] a) {
    if (a.length < size)
        // Make a new array of a's runtime type, but my contents:
        return (E[]) Arrays.copyOf(elementData, size, a.getClass());
    System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

    public static void main(String[] args) {

    TestGenerics<Integer> list = new TestGenerics<Integer>();
    list.add(1);
    list.add(2);
    list.add(3);
    //You don't have to do any casting
    Integer[] n = new Integer[10];
    n = list.toArray(n);
}
}

Is there any reason why it is declared that way?

Answer 1

From the javadocs:

Like the toArray() method, this method acts as bridge between array-based and collection-based APIs. Further, this method allows precise control over the runtime type of the output array, and may, under certain circumstances, be used to save allocation costs.

This means that the programmer is in control over what type of array it should be.

For example, for your ArrayList<Integer> instead of an Integer[] array you might want a Number[] or Object[] array.

Furthermore, the method also checks the array that is passed in. If you pass in an array that has enough space for all elements, the the toArray method re-uses that array. This means:

Integer[] myArray = new Integer[myList.size()];
myList.toArray(myArray);

or

Integer[] myArray = myList.toArray(new Integer[myList.size()]);

has the same effect as

Integer[] myArray = myList.toArray(new Integer[0]);

Note, in older versions of Java the latter operation used reflection to check the array type and then dynamically construct an array of the right type. By passing in a correctly sized array in the first place, reflection did not have to be used to allocate a new array inside the toArray method. That is no longer the case, and both versions can be used interchangeably.

Answer 2

It is declared generically so that you can write code such as

Integer[] intArray = list.toArray(new Integer[0]);

without casting the array coming back.

It is declared with the following annotation:

@SuppressWarnings("unchecked")

In other words, Java is trusting you to pass in an array parameter of the same type, so your error does not occur.

Answer 3

The reason why the method has this signature is because the toArray API predates generics: the method

 public Object[] toArray(Object[] a)

has been introduced as early as Java 1.2.

The corresponding generic that replaces Object with T has been introduced as a 100% backward-compatible option:

public <T> T[] toArray(T[] a)

Changing the signature to generic lets callers avoid the cast: prior to Java 5, callers needed to do this:

String[] arr = (String[])stringList.toArray(new String[stringList.size()]);

Now they can do the same call without a cast:

String[] arr = stringList.toArray(new String[stringList.size()]);

EDIT :

A more "modern" signature for the toArray method would be a pair of overloads:

public <T> T[] toArray(Class<T> elementType)
public <T> T[] toArray(Class<T> elementType, int count)

This would provide a more expressive, and equally versatile, alternative to the current method signature. There is an efficient implementation of this, too, with Array.newInstance(Class<T>,int) method in place. Changing the signature in this way would not be backward-compatible, though.

Answer 4

It is type-safe -- it doesn't cause a ClassCastException. That's generally what type-safe means.

ArrayStoreException is different. If you include ArrayStoreException in "not type-safe", then all arrays in Java are not type-safe.

The code that you posted also produces ArrayStoreException. Just try:

TestGenerics<Object> list = new TestGenerics<Object>();
list.add(1);
String[] n = new String[10];
list.toArray(n); // ArrayStoreException

In fact, it is simply not possible to allow the user to pass in an array of the type they want to get, and at the same time not have ArrayStoreException. Because any method signature that accepts an array of some type also allows arrays of subtypes.

So since it is not possible to avoid ArrayStoreException, why not make it as generic as possible? So that the user can use an array of some unrelated type if they somehow know that all the elements will be instances of that type?

Answer 5

The reason this method is as it is is mostly historic.

There is a difference between generic classes and array types: whereas the type parameters of generic class are erased at run-time, the type of the elements of arrays is not. So, at run-time, the JVM sees no difference between List<Integer> and List<String>, but it does see a difference between Integer[] and String[]! The reason for this difference is that arrays have always been there, from Java 1.0 onwards, whereas generics where only added (in a backward-compatible way) in Java 1.5.

The Collections API was added in Java 1.2, before the introduction of generics. At that time the List interface already contained a method

Object[] toArray(Object[] a);

(see this copy of the 1.2 JavaDoc). This was the only way to create an array with a user-specified runtime type: the parameter a served as a type token, that is, it determined the runtime type of the returned array (note that if A is a subclass of B, A[] is considered a subtype of B[] although List<A> is not a subtype of List<B>).

When generics were introduced in Java 1.5, many existing methods were made generic, and the toArray method became

<T> T[] toArray(T[] a);

which, after type erasure, has the same signature as the original non-generic method.

Answer 6

I think dasblinkenlight is probably correct that this has something to do with generifying an existing method, and full compatibility is a subtle thing to achieve.

beny23's point is also very good - the method should accept supertypes of E[]. One might attempt

    <T super E> T[] toArray(T[] a) 

but Java doesn't allow super on a type variable, for lack of use cases :)

(edit: nope, this is not a good use case for super, see https://stackoverflow.com/a/2800425/2158288)

Answer 7

This code is brutally copied from java.util.LinkedList class's source code:

public <T> T[] toArray(T[] a) {
    if (a.length < size)
        a = (T[])java.lang.reflect.Array.newInstance(
                            a.getClass().getComponentType(), size)
     // actual code for copying
     return a;
}

This should dl the trick

Answer 8

Finally with Java 11 we have a good compromise:

// Class Collection

default <T> T[] toArray(IntFunction<T[]> generator) {
    return toArray(generator.apply(0));
}

So if you provide array constructor it instantiate and copy data from collection to primitive array:

Set.of("a", "b").toArray(String[]::new);
List.of(1L, 2L).toArray(Long[]::new);