Search |
||
Parameterized type are NOT inherently unsafePosted by forax on May 27, 2008 at 6:17 AM PDT
Time to time, i heard that sentence
"array of generics a inherently unsafe"
or a variation.
Array of generics ? First, there are two kinds of "generics", type variable and parameterized type, and they behave differently. An example of array of type variable:
class A<T> { // T is a type variable
T[] m() { // T[] is an array of type variable
...
}
}
...
A<String> a =new A<String>();
Here, T is a type variable. A>String> is a parameterized type, it's an instantiation of A<T> with T = String.
As Gilad Bracha in the
generics tutorial
wrote
"The component type of an array object may not be a type variable or a parameterized type, unless it is an (unbounded) wildcard type",
Why ? Let's take the example given by Gilad: List<String>[] lsa = new List<String>[10]; // not really allowed Object o = lsa; Object[] oa = (Object[]) o; List<Integer> li = new ArrayList<Integer>(); li.add(new Integer(3)); oa[1] = li; // problem here String s = lsa[1].get(0);
Generics in Java are not reified, i.e. at runtime there
is no difference between a List<String> and
a List<Integer>, they are all List.
So the VM can perform runtime check to distinguish
between the two parameterized type.
So our example is erased to: List[] lsa = new List[10]; // not really allowed Object o = lsa; Object[] oa = (Object[]) o; List li = new ArrayList(); li.add(new Integer(3)); oa[1] = li; // problem but not detected here String s = lsa[1].get(0); // run-time error - ClassCastException So when VM execute the line oa[1] = li; it doesn't detect a problem. The VM generate a ClassCastException later here at the next line. To avoid to have a code that can generate a CCE without any warning, the JSR15 experts decide that array of parameterized type can not be created. Here comes the pain
Because you often need to create an array of parametrized type,
you have to use painful workaround.
An example of such tricks, the creation of an array of parametrized type is replaced by the creation of an array of wildcard then a cast.
List<String>[] list =
(List<String>[])new ArrayList<?>[1]; // warning
These workaround codes are very dangerous because if one day in the future generics are reified (JDK8 :), these codes will not work anymore and throw a ClassCastException. So what ?
So array creation is prohibited because it can lead
to unsafe code. I think it's time to say:
In general terms, the problem is that when converting an array of parameterized type to a type without type argument, the type is lost (by definition) so neither the compiler nor the VM (because of the erasure) can garantee the type safety. Unsafe convertion
Using a JLS like wording,
let T and U such as U is the declared type of u and T is
defined by, T t=u;
If this rule is added, creation of array of parameterized type is safe and then can be allowed. And what about the backward compatibility ?
With this new rule, program that compile will continue to
compile. Workarounds are not needed any more.
But some code that currently don't raise a warning
can now raise a warning.
SelectionKey key = ... List<String> list = ... key.attach(list); // will generate a new warning It's not a big deal because the following code already generate a warning.
List<String> list =
(List<String>)key.attachment(); // already generate a warning
The second case is more problematic List<String> list = ... System.out.println(list); // warning
Here, println take an Object, so the parameterized list
is assigned to an Object.
Hum, such warning is less desirable.
public void println(@SuppressWarnings("parameterized-type") Object x) {
I wish and hope, these changes can be included in JDK7. Is array of type variable inherently unsafe ? Yes, array of type variable are inherently unsafe. See the following code.
class A<T> {
T[] m() {
return new T[1]; // erasure create a, array of Object
}
}
...
A<String> a = new A<String>();
String[] s = a.m(); // oups
cheers,
Rémi »
Related Topics >>
Open JDK Comments
Comments are listed in date ascending order (oldest first)
Submitted by hlovatt on Thu, 2008-05-29 22:10.
@Rémi, this is probably a dumb question so please bare with me. How would your proposal deal with this:
@SuppressWarnings( "unchecked" ) final List<Double>[] lda = new List[ 1 ];
final List<? extends Number>[] lna = (List<? extends Number>[]) lda;
final List<Integer> li = Arrays.asList( 3 );
lna[ 0 ] = upCast( li ); // no problem now, types correct
final Double d = lda[ 0 ].get( 0 ); // runtime error generated here
Submitted by gafter on Tue, 2008-05-27 22:27.
Variable initialization is not the only place the warning would be required... everywhere the subtype relationship makes something legal, such a warning would be required. For example, using one of these "U" types as a type parameter must cause a warning (it is allowed because it is a subtype of the type parameter's bound, which by default is Object). If you apply this to its logical conclusion you'll find you can hardly do anything with these types without incurring the wrath of the compiler, and the causes would be far more difficut to understand than the status quo.
Submitted by hlovatt on Wed, 2008-05-28 00:16.
Wouldn't it be easier to stop erasing the types and whilst we are at it get rid of variance. (http://www.artima.com/weblogs/viewpost.jsp?thread=222021). Yes, it will break old code. But most things are generic these days, so they can be recompiled. We don't need to interact with raw types like we used too. I think it would now be worth the pain.
Submitted by forax on Thu, 2008-05-29 00:55.
Howard, reified generics is a must have and it's clear
that's no average duke understands variance.
About compatibility, in my opinion javac should now
warns on every raw types explicitly saying that it will
not work in 1.8.
Neal, i don't think you need a warning if the type
variable is not seen as an Object. The type variable
capture the type so there is no need to generate
a warning.
By example, the following code is safe:
<T> T m(T t) {
return t: // ok safe
}
but not this one:
<T> Object m(T t) {
return t; // warning here
}
Rémi
Submitted by hlovatt on Thu, 2008-05-29 02:38.
I think Neal is right:
static <T, S extends T> T upCast( final S s ) {
return s; // this needs to generate a warning for the new proposal
}
static void neal() {
@SuppressWarnings( "unchecked") final List<String>[] lsa = new List[ 10 ];
final Object[] oa = (Object[]) lsa;
final List<Integer> li = new ArrayList<Integer>();
li.add( new Integer( 3 ) );
oa[ 1 ] = upCast( li ); // no problem now, types correct
final String s = lsa[ 1 ].get( 0 ); // runtime error generated here
System.out.println( s );
}
|
||
|
|