T ...（泛型vararg参数）在编译时真的被剥离到Object []吗？

Question

(I'll use T to refer to a generic argument here, used in a parameterized class.)

I read that the reason that T... is a potential source of heap pollution when used as an argument is that the compiler is making an exception to the normal (no T[] arrays allowed) rule, and allowing T... (which is varargs, and so would normally translate by varargs rules internally to T[] , except that this isn't allowed with generics) as a parameter by implementing it internally as though it were a raw type, converting it to an array of Object[] instead.

So I wrote some code to verify this, to cement the concept into my memory.

I took T...t as an argument to a method, and then System.out.println 'd t.getClass[] . I expected to get the class of Object[] , but instead, I got T[] 's class.

So, it appears that the compiler is converting T...t to T[] internally, and not to Object[] .

eg

 public class MyClass<T>{
 public void method(T...t)
 {
    System.out.println(t.getClass().getName());  //for MyClass<String>, this gives me  
                                                 //[Ljava.lang.String

 }

What am I missing here? And if the compiler's not converting the generic varargs parameter internally to Object[] , how is it losing type safety and acting as a potential source of heap pollution?

Answer 1

void method(T... t)

gets converted to

void method(Object[] t)

so what you have heard is correct. But :

Integer a = 1, b = 2, c = 3;
method(a, b, c);

gets converted into:

Integer a = 1, b = 2, c = 3;
method(new Integer[] {a, b, c});

so the runtime type of t is Integer[] , even though its declared type (after compilation) is Object[] .