为什么在 Java 的类型转换期间允许在右侧使用（已擦除）泛型类型？

Question

This is disallowed, which I believe is due to type erasure. ( T is erased and cannot be accessed in runtime to read its class like T.class ).

class Cup<T> {
    private T t;
    public T[] getArray(int size) {
        Class<T> cls = T.class;
        return (T[]) Array.newInstance(cls, size);
    }
}

But how come this compiles? I thought the type conversion of (T)val would happen at runtime, thus the JVM would know nothing about if T is String or anything else. So javac should prevent the program from being compiled at all. would error out.

public class Cup<T> {
    public T get() {
        Integer val = 1;
        T result = (T)val;
        return result;
    }

    public static void main(String[] args) {
        Cup<String> cup = new Cup<>();
        System.out.println(cup.get());
    }
}

Did I miss anything on compile time vs runtime? Why this design choice? What is the intuition behind that?

Answer 1

This is called an unchecked narrowing reference conversion by the Java Lanaguage Spec . Allowing these casts is important for building some generic code. For example, they are used widely in implementing ArrayList , where the elements are stored in an Object[] and so static type checking is lost as items are added to and retrieved from the underlying array. However, because the compiler cannot perform the check statically nor at runtime, use of these conversions results in an unchecked warning :

If a narrowing reference conversion is unchecked, then the Java Virtual Machine will not be able to fully validate its type correctness, possibly leading to heap pollution. To flag this to the programmer, an unchecked narrowing reference conversion causes a compile-time unchecked warning, unless suppressed by @SuppressWarnings

These conversions exist solely in source code; they are not compiled into the bytecode and have no effect on the runtime. They are required solely to force the programmer to declare that they know (better than the compiler) that the conversion is safe.

Answer 2

You are correct that "the JVM would know nothing about if T is String or anything else", and as a result nothing will happen at runtime .

Normally, the runtime evaluation of a (reference type) cast would involve checking whether the object that you are casting actually is of the type that you are casting to. For example:

Object o = new Object();
String s = (String)o;

At runtime, a check is performed on o , and it will be found that o is actually of type Object and not String , and as such, a ClassCastException will be thrown.

On the other hand, if you are casting to a type parameter T , the runtime has no idea what T is, and so does not do any checking, hence this is an "unchecked cast", as the warning says.

So if val isn't actually of type T , no exceptions will be thrown:

Cup<String> c = new Cup<>();
c.get();

Even though I called get in the above code, and the line with the cast is executed, there will be no exceptions, because there is no runtime check. The runtime thinks that get returns an Object . It is only when the runtime knows what type to cast, does the cast happen, and the exception get thrown:

Cup<String> c = new Cup<>();
String s = c.get(); // this throws an exception

The compiler inserts the cast in the second line like so String s = (String)c.get();

As you can see, it doesn't really matter that the runtime doesn't know what T is at the line where the cast is, because you don't need the cast there anyway. Consider the type-erased version of your code:

public class Cup {
    public Object get() {
        Integer val = 1;
        Object result = val;
        return result;
    }
    public static void main(String[] args) {
        Cup cup = new Cup();
        System.out.println(cup.get());
    }
}

You'll notice that this is perfectly fine code that will compile!

(T)val here is mostly here to make the compiler happy, to convince the compiler that val is indeed of type T .