OK, I see. To me "array of generics" refers to what you want to
do when you implement an ArrayList (or any other array-based
data structure).

public class ArrayList<Item> {
   private Item[] elements;     // error: "can't create an array of
generics"
   ...

I'd very much like to do this. Generics are particularly useful with
collections and other data structures, but the language gets in your
way if you try to create your own.

Thomas Hawtin coughed up:

Arrays are objects that maintain their own type contents, which is generic
behavior, sure.  But in what way is this less safe than the rest of the
language?  It is certainly far safer than generics in general in that arrays
exhibit this behavior at runtime as well.

Sure, but he's not wrapping the array.  He's attempting to have an array of
a type of a type.

...[rip]...

Hmm, that's interesting. In that, they give the reason for avoiding this  
kind of thing as

    "This restriction is necessary to avoid situations like:

      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; // unsound, but passes run time store check
      String s = lsa[1].get(0); // run-time error - ClassCastException

    If arrays of parameterized type were allowed, the example above would
    compile without any unchecked warnings, and yet fail at run-time."

Perhaps it's just me, but I don't really see much difference between that  
and:

    List<String> lsa = new ArrayList<String>();     // ... but this is.
    Object o = lsa;
    Object[] oa = (Object[]) o;
    List<Integer> li = new ArrayList<Integer>();
    li.add(new Integer(3));
    oa[1] = li;            // still unsound, and *no* runtime store check
    String s = lsa.get(0); // run-time error - ClassCastException

Have I missed something, or is it just a pretty poor excuse. If the  
compiler couldn't check array access at all then I could understand the  
reasoning, but it can - I just can't see any real barriers that prevent  
generic array instantiation. What am I missing?

I think the current system achieves a reasonable balance between  
flexibility on the one hand, and performance and backward compatibility on  
the other. I'm not saying it's perfect (*far* from it), but I think that  
if they had gone the bytecode-generation route it would have been a lot  
less useful - an unrestricted number of new classes being generated on the  
fly, entirely 'under the hood' (i.e. outside your app's control). It might  
make even basic operations entirely unpredictable in terms of time,  
compromise security, and make it much more difficult to implement custom  
classloading strategies. I expect it's likely that the generics team  
started with something like above, given that bytecode generation is used  
elsewhere in the platform, and then worked backward to try to make it  
performant and compatible.

I think generics are a great convenience for working with collections, and  
useful in other situations too. I think the problem is more that they  
promise too much - it's natural to assume you can do things like  
T.newInstance() and new List<String>[40]. Erasure is certainly a minefield  
of ifs and elses, but I'm not convinced that creating separate classes  
under the hood is a viable alternative.

The problem with C++'s approach is that you don't use that class, you
use that *template*. There is no base GenericContainer class to cast
to, since there is no common base class Object.

It's quite easy to make a template system of your own, e.g. using Ant
to generate the concrete classes, if you find that to be sufficient.