Re: generic arrays
Roedy Green wrote:
Why does Java have a problem with:
// You cannot use "new" to allocate an array of T where T is a generic
type, e.g. <T>.
// Recall that even if it did, it would still allocate an array of
Objects at run time.
T[] things = new T[10];
The short answer:
Generics in Java, at present, is almost entirely a compile-time hack.
Anything which would have to be passed down into runtime cannot be done
without warning (e.g., casting, instanceof, new).
Why does it not just generate the code for:
Object[] things = new Object[10];
We were promised that things would be an array of T's. Communication
into the outside world would pass the runtime array store check (i.e.,
the array is initialized as an Object[]) but would violate the type safety.
public class GenericTest<T> {
private T[] array;
public GenericTest(int count) {
array = new T[count];
}
public void set(int place, T x) {
array[place] = x;
}
public T get(int place) {
return array[place];
}
public void malicious(Object insertee) {
Object[] evil = (Object[])array;
evil[0] = insertee;
}
public static void main(String... args) {
GenericTest<String> test = new GenericTest<String>(1);
test.malicious(new Object());
System.out.println(test.get(0) instanceof String);
}
}
Should new arrays be legal, this code would be forced to run with
unexpected output. The array is of type Object[], so inserting an Object
does not cause an ArrayStoreException when it should--it needs to be of
type T.
The process by which this issue would be fixed is called
reification--pushing generics down to the level of runtime, probably
with the addition of a few instructions to the JVM (anewarray, new, and
similar instructions having variants that pop classes from the stack is
my bet). It is also, IMO, the most needed change to Java.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth