Java擦除如何影响通用数组？

Question

I'm studying generics in this period and today I've found this mystery for me.

Let's consider the following dummy class:

    public class Main{

    public static void main(String[] args) { 
        Container<Integer> c = new Container<Integer>(); 

        c.getArray();                      //No Exception
        //c.getArray().getClass();         //Exception
        //int a = c.getArray().length;     //Exception

    } 

}


class Container<T> { 

    T[] array; 

    @SuppressWarnings("unchecked") 
    Container() { 
        array = (T[])new Object[1]; 
    } 

    void put(T item) { 
        array[0] = item; 
    } 

    T get() { return array[0]; } 

    T[] getArray() { return array; }
}  

Because of erasure, at runtime, the T[] return type of the getArray() method is turned into a Object[], which is completely reasonable to me.

If we access that method as it is (c.getArray()) no Exceptions are thrown, but if we try to call some methods on the returned array, for example c.Array().getClass(), or if we try to access to a field, for example c.getArray().length, then the following exception is thrown:

Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to [Ljava.lang.Integer;

Why is this Exception thrown? Why is it not thrown also for the simple c.getArray() call? Why is it trying to cast to Integer[] if we are simply calling getClass() or accessing length? Are getClass() and length not available also for Object[]?

Thanks in advance for your many (I hope) and explanatory (I hope this too) answers.

Answer 1

The reason for the exception is that the compiler expects a Integer[] but receives an Object[] . It added a run-time cast - at the call sites of getArray . Those casts discovered the lying, dummy, no-effect cast in your constructor.

For it to be correct, one needs the actual class of T, in order to create instances.

@SuppressWarnings("unchecked")
Container(Class<T> type) {
    array = (T[]) Array.newInstance(type, 10);
}


    Container<Integer> c = new Container<Integer>(Integer.class); 

    c.getArray();
    Class<?> t = c.getArray().getClass();
    System.out.println(t.getName());
    int a = c.getArray().length;

Also here remains an "unsafe" cast to T[] but this is unavoidable as Array.newInstance is a low-level method for n-dimensional arrays like in:

(double[][][][][][]) Array.newInstance(double.class, 3, 3, 3, 3, 3, 6);

Answer 2

I have not been able to find the exact place in the JLS which says this is the behaviour, but I think the reason is something like this:

The expression:

c.getArray().getClass();

is roughly equivalent to:

Integer[] arr = (Integer[]) c.getArray();
arr.getClass();

where the cast has to be added because of type erasure. This implicit cast adds a checkcast instruction in the bytecode, which fails with a ClassCastException , since c.getArray() is of type Object[] .

Looking at the bytecode for:

static void implicit() {
  Container<Integer> c = new Container<Integer>();
  c.getArray().getClass(); //Exception
}

static void explicit() {
  Container<Integer> c = new Container<Integer>();
  Integer[] arr = (Integer[]) c.getArray();
  arr.getClass(); //Exception
}

we get:

  static void implicit();
    Code:
       0: new           #2                  // class Container
       3: dup
       4: invokespecial #3                  // Method Container."<init>":()V
       7: astore_0
       8: aload_0
       9: invokevirtual #4                  // Method Container.getArray:()[Ljava/lang/Object;
      12: checkcast     #5                  // class "[Ljava/lang/Integer;"
      15: invokevirtual #6                  // Method java/lang/Object.getClass:()Ljava/lang/Class;
      18: pop
      19: return

  static void explicit();
    Code:
       0: new           #2                  // class Container
       3: dup
       4: invokespecial #3                  // Method Container."<init>":()V
       7: astore_0
       8: aload_0
       9: invokevirtual #4                  // Method Container.getArray:()[Ljava/lang/Object;
      12: checkcast     #5                  // class "[Ljava/lang/Integer;"
      15: checkcast     #5                  // class "[Ljava/lang/Integer;"
      18: astore_1
      19: aload_1
      20: invokevirtual #6                  // Method java/lang/Object.getClass:()Ljava/lang/Class;
      23: pop
      24: return

So the only difference in the explicit version are the three instructions:

      15: checkcast     #5                  // class "[Ljava/lang/Integer;"
      18: astore_1
      19: aload_1

Which are there only because of explicitly storing this in a variable, as far as I understand it.

Answer 3

When you do an unsafe unchecked cast, it may or may not cause an exception somewhere. You are not guaranteed to get an exception somewhere.

In this case, whether you get an exception depends on whether the compiler inserted a cast in the erased code to cast the result of the call to Integer[] . In this case, it seems a cast was inserted in the second and third case but not the first case.

In each of the three cases, the compiler is allowed to insert a cast (because it is allowed to assume that the result is Integer[] or not insert a cast (because the expression is used in such a way that only requires Object[] in all three). Whether to insert a cast or not is up to the particular compiler implementation to decide.

Why would this compiler not insert a cast in the first case and insert a cast in the second and third cases? One obvious explanation would be that in the first case, the result is obviously unused, so it is very simple to determine that a cast is unnecessary. In the second and third cases, to determine that a cast is unnecessary would require looking at how the expression is used to see that the it will also work with Object[] ; and this is a rather complicated analysis. The compiler authors probably opted for a simple approach where they skip the cast only when the result is unused.

Another compiler might insert casts in all three cases. And another compiler might have no casts in all three cases. You cannot rely on it.