Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Creating a generic array instance in a generic method

Tags:

java

arrays

I'm trying to build a helper method to turn the two line list to array conversion into a single line. The problem I've ran into is that I'm not sure how to create a a T[] instance.

I've tried

Array.newInstance(T.class, list.size) but I can't feed it T.class..

Also tried new T[](list.size) but it doesn't like the parameters.

public <T> T[] ConvertToArray(List<T> list)
{
   T[] result = ???

   result = list.toArray(result);

   return result;
}

Any other ideas?

Thanks

like image 815
Shane Courtrille Avatar asked Dec 02 '10 16:12

Shane Courtrille


People also ask

Can you create an array of generic type?

Java allows generic classes, methods, etc. that can be declared independent of types. However, Java does not allow the array to be generic. The reason for this is that in Java, arrays contain information related to their components and this information is used to allocate memory at runtime.

Can you instantiate a generic array?

Although we cannot instantiate a generic array of a specific type parameter, we can pass an already created array to a generic class constructor.

Why is generic array creation not allowed in Java?

If generic array creation were legal, then compiler generated casts would correct the program at compile time but it can fail at runtime, which violates the core fundamental system of generic types.


2 Answers

If you can't pass in T.class, then you're basically screwed. Type erasure means you simply won't know the type of T at execution time.

Of course there are other ways of specifying types, such as super type tokens - but my guess is that if you can't pass in T.class, you won't be able to pass in a type token either. If you can, then that's great :)

like image 22
Jon Skeet Avatar answered Oct 18 '22 04:10

Jon Skeet


You can't mix generics and arrays like that. Generics have compile-time checking, arrays have runtime checking, and those approaches are mostly incompatible. At first I suggested this:

@SuppressWarnings("unchecked")
public <T> T[] ConvertToArray(List<T> list)
{      
   Object[] result = new Object[list.size()];
   result = list.toArray(result);
   return (T[])result;
}

This is wrong in a stealthy way, as at least one other person on here thought it would work! However when you run it you get an incompatible type error, because you can't cast an Object[] to an Integer[]. Why can't we get T.class and create an array the right type? Or do new T[]?

Generics use type erasure to preserve backward compatibility. They are checked at compile time, but stripped from the runtime, so the bytecode is compatible with pre-generics JVMs. This means you cannot have class knowledge of a generic variable at runtime!

So while you can guarantee that T[] result will be of the type Integer[] ahead of time, the code list.toArray(result); (or new T[], or Array.newInstance(T.class, list.size());) will only happen at runtime, and it cannot know what T is!

Here's a version that does work, as a reward for reading that lecture:

public static <T> T[] convertToArray(List<?> list, Class<T> c) {
    @SuppressWarnings("unchecked")
    T[] result = (T[]) Array.newInstance(c, list.size());
    result = list.toArray(result);
    return (T[]) result;
}

Note that we have a second parameter to provide the class at runtime (as well as at compile time via generics). You would use this like so:

Integer[] arrayOfIntegers = convertToArray(listOfIntegers, Integer.class);

Is this worth the hassle? We still need to suppress a warning, so is it definitely safe?

My answer is yes. The warning generated there is just an "I'm not sure" from the compiler. By stepping through it, we can confirm that that cast will always succeed - even if you put the wrong class in as the second parameter, a compile-time warning is thrown.

The major advantage of doing this is that we have centralised the warning to one single place. We only need to prove this one place correct, and we know the code will always succeed. To quote the Java documentation:

the language is designed to guarantee that if your entire application has been compiled without unchecked warnings using javac -source 1.5, it is type safe[1]

So now rather than having these warnings all over your code, it's just in one place, and you can use this without having to worry - there's a massively reduced risk of you making a mistake by using it.

You may also want to look at this SO answer which explains the issue in more depth, and this answer which was my crib sheet when writing this. As well as the already cited Java documentation, another handy reference I used was this blog post by Neal Gafter, ex senior staff engineer at Sun Microsystems and co-designer of 1.4 and 5.0's language features.

And of course, thanks to ShaneC who rightly pointed out that my first answer failed at runtime!

like image 144
ZoFreX Avatar answered Oct 18 '22 03:10

ZoFreX