views:

591

answers:

11

Hello these,

This does not compile, any suggestion appreciated.

 ...
  List<Object> list = getList();
  return (List<Customer>) list;

Compiler says: cannot cast List<Object> to List<Customer>

+16  A: 

That's because although a Customer is an Object, a List of Customers is not a List of Objects. If it was, then you could put any object in a list of Customers.

Brian Agnew
In other words: You can't! (To answer the question)
DR
+1  A: 

You should just iterate over the list and cast all Objects one by one

vrm
+1  A: 

Your best bet is to create a new List<Customer>, iterate through the List<Object>, add each item to the new list, and return that.

Aric TenEyck
+3  A: 

Depending on your other code the best answer may vary. Try:

List<? extends Object> list = getList();
return (List<Customer>) list;

or

List list = getList();
return (List<Customer>) list;

But have in mind it is not recommended to do such unchecked casts.

Bozho
-1 - this is a really bad habit to get into, and unless you use the "Unchecked" annotation, the compiler will still complain about it
kdgregory
I added a note about it ;) (agreeing with you)
Bozho
+6  A: 

Note that I am no java programmer, but in .NET and C#, this feature is called contravariance or covariance. I haven't delved into those things yet, since they are new in .NET 4.0, which I'm not using since it's only beta, so I don't know which of the two terms describe your problem, but let me describe the technical issue with this.

Let's assume you were allowed to cast. Note, I say cast, since that's what you said, but there are two operations that could be possible, casting and converting.

Converting would mean that you get a new list object, but you say casting, which means you want to temporarily treat one object as another type.

Here's the problem with that.

What would happen if the following was allowed (note, I'm assuming that before the cast, the list of objects actually only contain Customer objects, otherwise the cast wouldn't work even in this hypothetical version of java):

List<Object> list = getList();
List<Customer> customers = (List<Customer>)list;
list.Insert(0, new someOtherObjectNotACustomer());
Customer c = customers[0];

In this case, this would attempt to treat an object, that isn't a customer, as a customer, and you would get a runtime error at one point, either form inside the list, or from the assignment.

Generics, however, is supposed to give you type-safe data types, like collections, and since they like to throw the word 'guaranteed' around, this sort of cast, with the problems that follow, is not allowed.

In .NET 4.0 (I know, your question was about java), this will be allowed in some very specific cases, where the compiler can guarantee that the operations you do are safe, but in the general sense, this type of cast will not be allowed. The same holds for java, although I'm unsure about any plans to introduce co- and contravariance to the java language.

Hopefully, someone with better java knowledge than me can tell you the specifics for the java future or implementation.

Lasse V. Karlsen
The future of Java is... Scala. Seriously, the guy who bolted generics onto Java has developed a new language that's vaguely similar to Java but really, really proficient with types: A very thorough and consistent implementation of type handling. I think no one knows for certain which Scala features will flow back into Java, and when.
Carl Smotricz
an excellent explanation of covariance that truly answers the OPs question. Well done.
Kevin Day
Carl: I thought some Java devs went ahead to create C#? :) Anyway yeah, Java is most likely going to the direction of Scala in the future instead of, say, something less strongly typed.
Esko
@Carl - in Scala there's a subtle difference in that by default Lists are immutable. So generally yo don't have the problem of adding an Object to a list of Customers, since when you do this you get a *new* list of *Objects*.
Brian Agnew
A: 

You can't because List<Object> and List<Customer> are not in the same inheritance tree.

You could add a new constructor to your List<Customer> class that takes a List<Object> and then iterate through the list casting each Object to a Customer and adding it to your collection. Be aware that an invalid cast exception can occur if the caller's List<Object> contains something that isn't a Customer.

The point of generic lists is to constrain them to certain types. You're trying to take a list that can have anything in it (Orders, Products, etc.) and squeeze it into a list that can only take Customers.

Rob Sobers
A: 

you can always cast any object to any type by up-casting it to Object first. in your case:

(List<Customer>)(Object)list;

you must be sure that at runtime the list contains nothing but Customer objects.

Critics say that such casting indicates something wrong with your code; you should be able to tweak your type declarations to avoid it. But Java generics is too complicated, and it is not perfect. Sometimes you just don't know if there is a pretty solution to satisfy the compiler, even though you know very well the runtime types and you know what you are trying to do is safe. In that case, just do the crude casting as needed, so you can leave work for home.

irreputable
A: 

As others have pointed out, you cannot savely cast them, since a List<Object> isn't a List<Customer>. What you could do, is to define a view on the list that does in-place type checking. Using Google Collections that would be:

return Lists.transform(list, new Function<Object, Customer>() {
  public Customer apply(Object from) {
    if (from instanceof Customer) {
      return (Customer)from;
    }
    return null; // or throw an exception, or do something else that makes sense.
  }
});
nd
A: 

Similar with Bozho above. You can do some workaround here (although i myself don't like it) through this method :

public <T> List<T> convert(List list, T t){
    return list;
}

Yes. It will cast your list into your demanded generic type.

In the given case above, you can do some code like this :

    List<Object> list = getList();
    return convert(list, new Customer());
Hendra Jaya
A: 

You can use a double cast.

return (List<Customer>) (List) getList();
Peter Lawrey
A: 

Depending on what you want to do with the list, you may not even need to cast it to a List<Customer>. If you only want to add Customer objects to the list, you could declare it as follows:

...
List<Object> list = getList();
return (List<? super Customer>) list;

This is legal (well, not just legal, but correct - the list is of "some supertype to Customer"), and if you're going to be passing it into a method that will merely be adding objects to the list then the above generic bounds are sufficient for this.

On the other hand, if you want to retrieve objects from the list and have them strongly typed as Customers - then you're out of luck, and rightly so. Because the list is a List<Object> there's no guarantee that the contents are customers, so you'll have to provide your own casting on retrieval. (Or be really, absolutely, doubly sure that the list will only contain Customers and use a double-cast from one of the other answers, but do realise that you're completely circumventing the compile-time type-safety you get from generics in this case).

Broadly speaking it's always good to consider the broadest possible generic bounds that would be acceptable when writing a method, doubly so if it's going to be used as a library method. If you're only going to read from a list, use List<? extends T> instead of List<T>, for example - this gives your callers much more scope in the arguments they can pass in and means they are less likely to run into avoidable issues similar to the one you're having here.

Andrzej Doyle