How to Create a Generic Array in Java

How to create a generic array in Java?

I have to ask a question in return: is your GenSet "checked" or "unchecked"?
What does that mean?

• Checked: strong typing. GenSet knows explicitly what type of objects it contains (i.e. its constructor was explicitly called with a Class<E> argument, and methods will throw an exception when they are passed arguments that are not of type E. See Collections.checkedCollection.

  -> in that case, you should write:

  public class GenSet<E> {
  
      private E[] a;
  
      public GenSet(Class<E> c, int s) {
          // Use Array native method to create array
          // of a type only known at run time
          @SuppressWarnings("unchecked")
          final E[] a = (E[]) Array.newInstance(c, s);
          this.a = a;
      }
  
      E get(int i) {
          return a[i];
      }
  }
  

• Unchecked: weak typing. No type checking is actually done on any of the objects passed as argument.

  -> in that case, you should write

  public class GenSet<E> {
  
      private Object[] a;
  
      public GenSet(int s) {
          a = new Object[s];
      }
  
      E get(int i) {
          @SuppressWarnings("unchecked")
          final E e = (E) a[i];
          return e;
      }
  }
  

  Note that the component type of the array should be the erasure of the type parameter:

  public class GenSet<E extends Foo> { // E has an upper bound of Foo
  
      private Foo[] a; // E erases to Foo, so use Foo[]
  
      public GenSet(int s) {
          a = new Foo[s];
      }
  
      ...
  }
  

All of this results from a known, and deliberate, weakness of generics in Java: it was implemented using erasure, so "generic" classes don't know what type argument they were created with at run time, and therefore can not provide type-safety unless some explicit mechanism (type-checking) is implemented.

How to create a generic array?

You should not mix-up arrays and generics. They don't go well together. There are differences in how arrays and generic types enforce the type check. We say that arrays are reified, but generics are not. As a result of this, you see these differences working with arrays and generics.

Arrays are covariant, Generics are not:

What that means? You must be knowing by now that the following assignment is valid:

Object[] arr = new String[10];

Basically, an Object[] is a super type of String[], because Object is a super type of String. This is not true with generics. So, the following declaration is not valid, and won't compile:

List<Object> list = new ArrayList<String>(); // Will not compile.

Reason being, generics are invariant.

Enforcing Type Check:

Generics were introduced in Java to enforce stronger type check at compile time. As such, generic types don't have any type information at runtime due to type erasure. So, a List<String> has a static type of List<String> but a dynamic type of List.

However, arrays carry with them the runtime type information of the component type. At runtime, arrays use Array Store check to check whether you are inserting elements compatible with actual array type. So, the following code:

Object[] arr = new String[10];
arr[0] = new Integer(10);

will compile fine, but will fail at runtime, as a result of ArrayStoreCheck. With generics, this is not possible, as the compiler will try to prevent the runtime exception by providing compile time check, by avoiding creation of reference like this, as shown above.

So, what's the issue with Generic Array Creation?

Creation of array whose component type is either a type parameter, a concrete parameterized type or a bounded wildcard parameterized type, is type-unsafe.

Consider the code as below:

public <T> T[] getArray(int size) {
    T[] arr = new T[size];  // Suppose this was allowed for the time being.
    return arr;
}

Since the type of T is not known at runtime, the array created is actually an Object[]. So the above method at runtime will look like:

public Object[] getArray(int size) {
    Object[] arr = new Object[size];
    return arr;
}

Now, suppose you call this method as:

Integer[] arr = getArray(10);

Here's the problem. You have just assigned an Object[] to a reference of Integer[]. The above code will compile fine, but will fail at runtime.

That is why generic array creation is forbidden.

Why typecasting new Object[10] to E[] works?

Now your last doubt, why the below code works:

E[] elements = (E[]) new Object[10];

The above code have the same implications as explained above. If you notice, the compiler would be giving you an Unchecked Cast Warning there, as you are typecasting to an array of unknown component type. That means, the cast may fail at runtime. For e.g, if you have that code in the above method:

public <T> T[] getArray(int size) {
    T[] arr = (T[])new Object[size];        
    return arr;
}

and you call invoke it like this:

String[] arr = getArray(10);

this will fail at runtime with a ClassCastException. So, no this way will not work always.

What about creating an array of type List<String>[]?

The issue is the same. Due to type erasure, a List<String>[] is nothing but a List[]. So, had the creation of such arrays allowed, let's see what could happen:

List<String>[] strlistarr = new List<String>[10];  // Won't compile. but just consider it
Object[] objarr = strlistarr;    // this will be fine
objarr[0] = new ArrayList<Integer>(); // This should fail but succeeds.

Now the ArrayStoreCheck in the above case will succeed at runtime although that should have thrown an ArrayStoreException. That's because both List<String>[] and List<Integer>[] are compiled to List[] at runtime.

So can we create array of unbounded wildcard parameterized types?

Yes. The reason being, a List<?> is a reifiable type. And that makes sense, as there is no type associated at all. So there is nothing to loose as a result of type erasure. So, it is perfectly type-safe to create an array of such type.

List<?>[] listArr = new List<?>[10];
listArr[0] = new ArrayList<String>();  // Fine.
listArr[1] = new ArrayList<Integer>(); // Fine

Both the above case is fine, because List<?> is super type of all the instantiation of the generic type List<E>. So, it won't issue an ArrayStoreException at runtime. The case is same with raw types array. As raw types are also reifiable types, you can create an array List[].

So, it goes like, you can only create an array of reifiable types, but not non-reifiable types. Note that, in all the above cases, declaration of array is fine, it's the creation of array with new operator, which gives issues. But, there is no point in declaring an array of those reference types, as they can't point to anything but null (Ignoring the unbounded types).

Is there any workaround for E[]?

Yes, you can create the array using Array#newInstance() method:

public <E> E[] getArray(Class<E> clazz, int size) {
    @SuppressWarnings("unchecked")
    E[] arr = (E[]) Array.newInstance(clazz, size);

    return arr;
}

Typecast is needed because that method returns an Object. But you can be sure that it's a safe cast. So, you can even use @SuppressWarnings on that variable.

Why can't I create generic array in Java?

You can't create a generic array in Java. Arrays are reifiable types, and carry their type information at runtime whereas generics are non reifiable, and their type information is erased after the compile time due to erasure. This is due to the implementation of the type system in java and even though this causes some rough edges and corner cases, it eases the evolution of code into generics. Since generic type information is erased, you don't have them at runtime and that's why you can't create a generic array in java.

There are two solutions to circumvent the issue you are facing. You can either create an Object array and cast it to the generic type you need.

final T[] arr = (T[]) new Object[n]

or else

final Object[] arr = new Object[]

You can do the cast when you get the items from this array like this

T itm = (T) arr[1];

Both of the above approaches work if you don't return this internal array.

However, if you are returning the internal array, you need to create it reflectively, since you need to maintain the proper reifiable type.

static <T> T[] createArr(Class<T> clz) {
    return (T[]) Array.newInstance(clz, 5);
}

Java Generic array creation allowed?

The code is allowed because new jj[10] is not a generic array (e.g. new T[10]), but is instead an array of raw jj instances - jj with its generic arguments omitted. new jj[10] creates a new array of raw jj, not a new array of jj<Integer>. Java allows one to force instances of a raw type to be assigned to a reference of type with generic arguments as the code does with jj<Integer>[] lol = new jj[10];. I believe this is there for backwards compatibility with pre-Java 5 code.

Creating generic array in Java

You can use this method from guava

  static <T> T[] newArray(T[] reference, int length) {
    Class<?> type = reference.getClass().getComponentType();
    @SuppressWarnings("unchecked")
    T[] result = (T[]) Array.newInstance(type, length);
    return result;
  }

Generic array creation error

You can't have arrays of generic classes. Java simply doesn't support it.

You should consider using a collection instead of an array. For instance,

public static ArrayList<List<MyObject>> a = new ArrayList<List<MyObject>();

Another "workaround" is to create an auxilliary class like this

class MyObjectArrayList extends ArrayList<MyObject> { }

and then create an array of MyObjectArrayList.

---

Here is a good article on why this is not allowed in the language. The article gives the following example of what could happen if it was allowed:

List<String>[] lsa = new List<String>[10]; // illegal
Object[] oa = lsa;  // OK because List<String> is a subtype of Object
List<Integer> li = new ArrayList<Integer>();
li.add(new Integer(3));
oa[0] = li; 
String s = lsa[0].get(0); 

Create a generic array in java

Well you can use a raw type:

Tuple[] array = new Tuple[6];

Or you can make an unchecked conversion:

Tuple<byte[], Integer>[] array = (Tuple<byte[], Integer>[])new Tuple[6];

// or just this because raw types let you do it
Tuple<byte[], Integer>[] array = new Tuple[6];

Or you can use a List instead:

List<Tuple<byte[], Integer>> list = new ArrayList<Tuple<byte[], Integer>>();

I recommend using a List instead.

Choosing between the first two options, I would recommend the unchecked conversion because it will provide you with compile-time checks. However, it will not throw an ArrayStoreException if you put some other kind of Tuple in it.

How to create a generic array in Java

Use java.lang.reflect.Array#newInstance:

car<T>[] name = (car<T>[]) java.lang.reflect.Array.newInstance(car.class, 5);

Creating generic array in Java via unchecked type-cast

Since I was mentioned in the question, I will chime in.

Basically, it will not cause any problems if you don't expose this array variable to the outside of the class. (kinda like, What happens in Vegas stays in Vegas.)

The actual runtime type of the array is Object[]. So putting it into a variable of type Bar[] is effectively a "lie", since Object[] is not a subtype of Bar[] (unless Object is Bar). However, this lie is okay if it stays inside the class, since Bar is erased to Object inside the class. (The lower bound of Bar is Object in this question. In a case where the lower bound of Bar is something else, replace all occurrences of Object in this discussion with whatever that bound is.) However, if this lie gets somehow exposed to the outside (the simplest example is returning the bars variable directly as type Bar[], then it will cause problems.

To understand what is really going on, it is instructive to look at the code with and without generics. Any generics program can be re-written into an equivalent non-generics program, simply by removing generics and inserting casts in the right place. This transformation is called type erasure.

We consider a simple implementation of Foo<Bar>, with methods for getting and setting particular elements in the array, as well as a method for getting the whole array:

class Foo<Bar> {
    Bar[] bars = (Bar[])new Object[5];
    public Bar get(int i) {
        return bars[i];
    }
    public void set(int i, Bar x) {
        bars[i] = x;
    }
    public Bar[] getArray() {
        return bars;
    }
}

// in some method somewhere:
Foo<String> foo = new Foo<String>();
foo.set(2, "hello");
String other = foo.get(3);
String[] allStrings = foo.getArray();

After type erasure, this becomes:

class Foo {
    Object[] bars = new Object[5];
    public Object get(int i) {
        return bars[i];
    }
    public void set(int i, Object x) {
        bars[i] = x;
    }
    public Object[] getArray() {
        return bars;
    }
}

// in some method somewhere:
Foo foo = new Foo();
foo.set(2, "hello");
String other = (String)foo.get(3);
String[] allStrings = (String[])foo.getArray();

So there are no casts inside the class anymore. However, there are casts in the calling code -- when getting one element, and getting the entire array. The cast to get one element should not fail, because the only things we can put into the array are Bar, so the only things we can get out are also Bar. However, the cast when getting the entire array, that will fail, since the array has actual runtime type Object[].

Written non-generically, what is happening and the problem become much more apparent. What is especially troubling is that the cast failure does not happen in the class where we wrote the cast in generics -- it happens in someone else's code that uses our class. And that other person's code is completely safe and innocent. It also does not happen at the time where we did our cast in the generics code -- it happens later, when someone calls getArray(), without warning.

If we didn't have this getArray() method, then this class would be safe. With this method, it is unsafe. What characteristic makes it unsafe? It returns bars as type Bar[], which depends on the "lie" we made earlier. Since the lie is not true, it causes problems. If the method had instead returned the array as type Object[], then it would be safe, since it does not depend on the "lie".

People will tell you to not do such a cast like this, because it causes cast exceptions in unexpected places as seen above, not in the original place where the unchecked cast was. The compiler will not warn you that getArray() is unsafe (because from its point of view, given the types you told it, it is safe). Thus it depends on the programmer to be diligent about this pitfall and not to use it in an unsafe way.

However, I would argue that this is not a big concern in practice. Any well-designed API will never expose internal instance variables to the outside. (Even if there is a method to return the contents as an array, it would not return the internal variable directly; it would copy it, to prevent outside code from modifying the array directly.) So no method will be implemented like getArray() is anyway.

---

Related Topics