tags:

views:

659

answers:

5

I want to create an array of Classes, each representing a type that is available in the system I'm building. All the Classes involved are subclasses of a common superclass. So I'd like to do:

Class<? extends SuperClass>[] availableTypes = { SubClass1.class, SubClass2.class };

This gives me the error:

Cannot create a generic array of Class<? extends SuperClass>.

I get the same message if I try to qualify the creation of the array on the right hand side of the initialization:

Class<? extends SuperClass>[] availableTypes = Class<? extends SuperClass>[] { SubClass1.class, SubClass2.class };

I can get the code to compile if I eliminate the generics qualifications:

Class[] availableTypes = { SubClass1.class, SubClass2.class };

But then I get the generics warning:

Class is a raw type. References to generic type Class should be parameterized.

I'm trying; I'm trying! :) Also, at this point, even if this didn't provoke a warning, I lose a piece of the interface I was trying to define. I don't want to just return an array of arbitrary classes; I want to return an array of classes that are all subclasses of a particular SuperClass!

Eclipse has some pretty powerful tools for figuring out what parameters to use to fix generics declarations, but in this case it falls down, as it tends to do when you deal with Class. The "Infer Generic Type Arguments" procedure it offers doesn't change the code at all, leaving the warning.

I was able to work around this by using a Collection instead:

List<Class<? extends SuperClass>> availableTypes = new List<Class<? extends SuperClass>>();

But what's the right way to do this with arrays?

+3  A: 

It seems a bit defeatist, but problems like this are precisely the reason why most people avoid mixing arrays and generics. Because of the way generics are implemented (type erasure), arrays and generics will never work well together.

Two workarounds:

  • Stick to using a collection (e.g. ArrayList<Class<? extends SuperClass>>), which works just as well as an array and also allows expansion.
  • Put a @SuppressWarnings("unchecked") annotation on the code creating the array along with a comment justifying its use.
Simon Nickerson
+2  A: 

The problem is that it is illegal to create an array of a generic type. The only way to get around it is by casting to the generic type when you create the array, but that's not a very good solution. (Note that it is possible to use a generic array, just not create one: see this question.)

You should almost always be using lists instead of arrays anyway, so I think you came up with the best solution already.

Michael Myers
+1  A: 

Use this syntax:

Class<? extends SuperClass>[] avail = new Class[] { SubClass1.class, ... };

It will give you an "unchecked" warning, and rightly so, since you might be including a Class object for a type that doesn't extend SuperClass in the array.

erickson
+2  A: 

The right way to do this with arrays is to do it with a Collection. Sorry! For a complicated set of reasons, arrays don't play nice with generics. Arrays have a different covariance model than generic objects do, which ultimately causes the problems you are running into. For example, with arrays, but not (normally) with generic objects, you can legally do this:

Object[] myArray = new String[5];

while you cannot do this:

LinkedList<Object> myCollection = new LinkedList<String>();

If you want more detail, you can see the Arrays In Java Generics page from the excellent Generics FAQ

As simonn said, you can also just use your arrays as they are, and use @SuppressWarnings("unchecked") to silence the warnings. This will function, but without the type safety that generics can provide you. If it's performance that you are worried about, just use an ArrayList so you are just using a thin wrapper around an array, but with all of the type safety guarantees provided by generics.

Eddie
Covariance! You said the bad word!
Torsten Marek
+1  A: 

But what's the right way to do this with arrays?

There's no type-safe way to do this; using the collection is the right approach. To see why, imagine if this were allowed. You could have a situation like this:

// Illegal!
Object[] baskets = new FruitBasket<? extends Citrus>[10];

// This is okay.
baskets[0] = new FruitBasket<Lemon>();

// Danger! This should fail, but the type system will let it through.
baskets[0] = new FruitBasket<Potato>();

The type system needs to detect whether a basket that gets added to the array is of the type FruitBasket<? extends Citrus> or a subtype. A FruitBasket does not match and should be rejected with an ArrayStoreException. But nothing happens!

Because of type erasure, the JVM can only see the runtime type of the array. At runtime, we need to compare the array type to the element type to make sure they match. The array's runtime component type is FruitBasket[] after type erasure; likewise, the element's runtime type is FruitBasket. No problems will be detected -- and that's why this is dangerous.

John Feminella