Is List<Dog> a subclass of List<Animal>? Why are Java generics not implicitly polymorphic?
Asked Answered
S

19

908

I'm a bit confused about how Java generics handle inheritance / polymorphism.

Assume the following hierarchy -

Animal (Parent)

Dog - Cat (Children)

So suppose I have a method doSomething(List<Animal> animals). By all the rules of inheritance and polymorphism, I would assume that a List<Dog> is a List<Animal> and a List<Cat> is a List<Animal> - and so either one could be passed to this method. Not so. If I want to achieve this behavior, I have to explicitly tell the method to accept a list of any subclass of Animal by saying doSomething(List<? extends Animal> animals).

I understand that this is Java's behavior. My question is why? Why is polymorphism generally implicit, but when it comes to generics it must be specified?

Seed answered 30/4, 2010 at 14:39 Comment(11)
And a totally unrelated grammar question that's bothering me now - should my title be "why aren't Java's generics" or "why isn't Java's generics"?? Is "generics" plural because of the s or singular because it's one entity?Seed
generics as done in Java are a very poor form of parametric polymorphism. Don't put too much into faith into them (like I used to), because one day you'll hit hard their pathetic limitations: Surgeon extends Handable<Scalpel>, Handable<Sponge> KABOOM! Does not compute [TM]. There's your Java generics limitation. Any OOA/OOD can be translated fine into Java (and MI can be done very nicely using Java interfaces) but generics just don't cut it. They're fine for "collections" and procedural programming that said (which is what most Java programmers do anyway so...).Lyceum
Super class of List<Dog> is not List<Animal> but List<?> (i.e list of unknown type) . Generics erases type information in compiled code. This is done so that code which is using generics(java 5 & above) is compatible with earlier versions of java without generics.Deliverance
Related SO question - Whats the use of saying <? extends SomeObject> instead of <SomeObject>Momism
Just like to add that there is actually an Official Java Tutorial concerning this topic: docs.oracle.com/javase/tutorial/extra/generics/subtype.htmlDogtooth
@Seed since nobody seemed to respond... it should definitely be "why aren't Java's generics...". The other issue is that "generic" is actually an adjective, and so "generics" is referring to a dropped plural noun modified by "generic". You could say "that function is a generic", but that would be more cumbersome than saying "that function is generic". However, it's a bit cumbersome to say "Java has generic functions and classes", instead of just "Java has generics". As someone who wrote their master's thesis on adjectives, I think you've stumbled upon a very interesting question!Vellum
List<A> has no relationship with List<B> regardless of the relationship between class A and B.Feudist
@Vellum Generics could be viewed as a collective singular, in which case "isn't" works just fine.Faris
@Lyceum In your example, my goto solution would be making a super-interface of Scalpel and Sponge (probably named something like SurgeonItem) then declaring Surgeon extends Handable<SurgeonItem>.Anaphrodisiac
@Deliverance List<?> isn't the only effective supertype of List<Dog>. Other examples are List<? extends Dog> and List<? super Dog>. Also, any variant of the four (<Dog>, <? super Dog>, <? extends Dog>, <?>) applied to a supertype of List apply as well: Collection<Dog>, Iterable<? super Dog>, etc.. Anywhere you have a reference to any of those you can also pass in a List<Dog>. Also List<? extends Animal> and List<? super Chihuahua>.Influential
Related: What is PECS (Producer Extends Consumer Super)?Dorton
T
1063

No, a List<Dog> is not a List<Animal>. Consider what you can do with a List<Animal> - you can add any animal to it... including a cat. Now, can you logically add a cat to a litter of puppies? Absolutely not.

// Illegal code - because otherwise life would be Bad
List<Dog> dogs = new ArrayList<Dog>(); // ArrayList implements List
List<Animal> animals = dogs; // Awooga awooga
animals.add(new Cat());
Dog dog = dogs.get(0); // This should be safe, right?

Suddenly you have a very confused cat.

Now, you can't add a Cat to a List<? extends Animal> because you don't know it's a List<Cat>. You can retrieve a value and know that it will be an Animal, but you can't add arbitrary animals. The reverse is true for List<? super Animal> - in that case you can add an Animal to it safely, but you don't know anything about what might be retrieved from it, because it could be a List<Object>.

Tact answered 30/4, 2010 at 14:44 Comment(38)
Interestingly, every list of dogs is indeed a list of animals, just like intuition tells us. The point is, that not every list of animals is a list of dogs, hence mutattion of the list by adding a cat is the problem.Macaluso
@Ingo: No, not really: you can add a cat to a list of animals, but you can't add a cat to a list of dogs. A list of dogs is only a list of animals if you consider it in a read-only sense.Tact
@JonSkeet - Of course, but who is mandating that making a new list from a cat and a list of dogs actually changes the list of dogs? This is an arbitrary implementation decision in Java. One that goes counter to logic and intuition.Macaluso
@Ingo: The point is that we're speaking in the context of Java, where these things are specified. I don't think that taking it out of that context is really helpful. (And even in real life, in various cases if you start adding "the wrong type of item" to a list, the list no longer makes sense.)Tact
@JonSkeet I do not want to be nitpicking, but if you included the words "subclass of" after the first occurence of "not a" in your answer, it would get very much better. Or even: "While a list of dogs is certainly a list of animals, this does unfortunately not mean that a List<Dog> is a subtype of List<Animal>"Macaluso
@Ingo: I wouldn't have used that "certainly" to start with. If you have a list which says at the top "Hotels we might want to go to" and then someone added a swimming pool to it, would you think that valid? No - it's a list of hotels, which isn't a list of buildings. And it's not like I even said "A list of dogs is not a list of animals" - I put it in code terms, in a code font. I really don't think there's any ambiguity here. Using subclass would be incorrect anyway - it's about assignment compatibility, not subclassing.Tact
I think the problem with this line of argument is that the contract of List<Animal> actually doesn't specify that you can add any Animal to it. List implementations are allowed to be completely immutable, or to be fixed-length, or to have arbitrary restrictions on what elements you can add (e.g. based on their runtime type). Note that a Dog[] is an Animal[], with forbidden assignments being blocked at runtime. (With List<Dog> that can't be done, in general, due to erasure.) If we want to view this as something other than a failure of language design, I think we need [continued]Intreat
[continued] to use examples like Comparable<Dog>, where it makes sense to say that Comparable<Dog> ("can be compared to any Dog") does not imply Comparable<Animal> ("can be compared to any Animal").Intreat
@ruakh: The problem is that you're then punting to execution time something which can be blocked at compile-time. And I'd argue that array covariance was a design mistake to start with.Tact
Java allows doing that example when using arrays. At compile time you wouldn't have any problems with that. But at runtime a cast exception would be thrown. Please explain me why this is possible with arrays, but not with generic lists. In my opinion this behavior is not consistent. I could imagine that the java developers decided to not keep this behavior anymore as they introduced generics.Leisured
@GinoBambino: Firstly, I view the covariance of arrays as a mistake to start with. (And a mistake that .NET copied, to my annoyance.) Secondly, with the way generics are implemented in Java, it couldn't be caught at execution time - a String[] knows it's really a String[] rather than an Object[], but an ArrayList<String> doesn't know that. As for why the array behaviour wasn't changed when generics were introduced - that would have been a massive breaking change. That was never going to happen.Tact
I agree with you that the covariance of arrays can quickly introduce bugs in the code, therefore it should be considered as a mistake. In contrast to Java .NET can differ between List<Object> and List<String), but the above example is also not allowed. I suppose that there are not only technical reasons that argue against this. In Java it may be (because of type erasure)^^Leisured
@Macaluso "Who is mandating that making a new list from a cat and a list of dogs actually changes the list of dogs?" This is inherent in the nature of references. In the code snippet above, the variables named dogs and animals refer to the same object.Sexless
Is not it the same as: Cat cat = new Cat(); Object o = cat; Dog dog = (Dog) o; ? This will compileFae
@atomAltera: No, because the aim of generics is to implicitly add casts that are expected to work.Tact
Just out of curiosity, is there a reference to the Monty Python's sketch "Confuse a cat"? Or is it just a pure coincidence?Sigfried
@LucaCremonesi: That's just coincidence. Monty Python references elsewhere may well be intentional.Tact
@Ingo: the reason why the intuition fails here is that it works with immutable lists, rather than shared references to mutable lists. Java offers such a view if you ensure immutability, i.e. you can write List<Animal> animals = Collections.unmodifiableList(dogs);. Since the animals view doesn't allow mutations, it is safe.Gottlieb
The whole argument here can be resolved by stating that supertyping generics parameter is safe when the generic class is immutable. @JonSkeet and @Gottlieb clearly state it and nobody argued against it. I myself do see some interesting implications when we apply this to java.lang.Class<T>.Straightaway
Hi Jon, nice argument and vote up, but it seems array works and doesn't array has the same issue of List? Why array works, but not List? See my new post and code here => #42897825Staciestack
@LinMa: Arrays are designed fundamentally differently, and show problems at execution time instead of compile time.Tact
When you expect a list of animals, you do not care if it is a dog, a cat, or a crocodile.Metre
@Yar: You do if you're trying to add to that list of animals. If you're just consuming, that's a different matter. And that's why an IEnumerable<Dog> is an IEnumerable<Animal>, but a List<Dog> isn't a List<Animal>.Tact
@Jon Skeet If I want to add a dog, a cat, a bird to a list of animals - that should be OK, because i always consume an animal, not a dog. If I cast an animal to a dog - that is my problem and responsibility to make sure it is a dog. So - still we have a misunderstanding. Maybe Java is wrong? maybe lists should be more flexible? If a developer wants to LOSE all the benefits of the list of dogs, and treat them as animals - that should be OK. List should "morph" somehow on the fly. Java should adapt to human intuition, not vice versa - in my humble opinion.Metre
@Yar: Ignore my IEnumerable<T> part from the previous comment - I'd forgotten this was about Java, not C#. (They have differences, but both are similar.) But no, I don't think Java is wrong - because different pieces of code can be regarding the same object as different types. Suppose you could treat List<Dog> as a List<Animal>. Then you could have: List<Dog> dogs = new ArrayList<Dog>(); List<Animal> animals = dogs; animals.add(new Cat()); Dog dog = dogs.get(0);. What would you want that to do? I want it to fail as early as possible, at compile-time - which is what it does right now.Tact
@Yar: I don't want the list to "morph" a Cat into a Dog. I want to have - and do have - ways of saying, "Hey, I'm only consuming the list, and everything should be an animal" - so you use List<? extends Animal>, and you don't get to add to the list. That seems fine to me. In general, trying to make programming languages match "human intuition" sounds great, until you realise it becomes ambiguous, and everyone has different intuition.Tact
@Jon Skeet OK, thanks, now you have convinced me. With this: List<Animal> animals = dogs; animals.add(new Cat()); Dog dog = dogs.get(0);Metre
how about List<? extends Animal> ?Drowsy
@SaqibJaved: Yes, at that point you can retrieve Animal values, but not add anything - as per the last paragraph of my answer.Tact
As a side note to the previous comment, PECS is involved here if you're writing method signatures. Producer = extends, Consumer = super. That is, if a collection is producing elements for you (i.e. you're reading from it), you use extends. However, if it's consuming elements (i.e. you're adding to it), you use super.Chiasmus
upvote just for the entertainment value of the answerPapilla
It's contravariance.Wheal
@Alex78191: It's unclear to me exactly which part of this long thread you're referring to.Tact
@JonSkeet to the answerWheal
@Alex78191: You mean List<? extends Animal> animals = new ArrayList<Dog>(); ? I believe that's demonstrating covariance rather than contravariance. (List<? super Dog> dogs = new ArrayList<Animal>(); would be demonstrating contravariance.)Tact
@Metre I strongly disagree. If I have a list of dogs, I want to be able to write if (! listOfDogs.isEmpty()) { listOfDogs.get(0).bark(); } - but if there's a possibility that listOfDogs has become a list of assorted dogs, cats and birds, then I'd want the compiler to stop me doing that. And if the compiler's going to do that, then I may as well just have a List<Animal> all along. Having a List<Dog> means that I can guarantee that anything I get out of the list is going to be able to do doggy things, like bark().Candlelight
This kind of behavior makes sense to me (whereas a List<Dog> can't be cast to List<Animal>) but what really irks me is that arrays can behave this way: ((Animal[]) new Dog[10])[0] = new Cat();. No compilation error, not even a warning. An ArrayStoreException is thrown when run of course, however.Anaphrodisiac
this same problem exists for any supertype, not just ListsWaterrepellent
G
111

What you are looking for is called covariant type parameters. This means that if one type of object can be substituted for another in a method (for instance, Animal can be replaced with Dog), the same applies to expressions using those objects (so List<Animal> could be replaced with List<Dog>). The problem is that covariance is not safe for mutable lists in general. Suppose you have a List<Dog>, and it is being used as a List<Animal>. What happens when you try to add a Cat to this List<Animal> which is really a List<Dog>? Automatically allowing type parameters to be covariant breaks the type system.

It would be useful to add syntax to allow type parameters to be specified as covariant, which avoids the ? extends Foo in method declarations, but that does add additional complexity.

Grizzled answered 30/4, 2010 at 14:44 Comment(0)
G
51

The reason a List<Dog> is not a List<Animal>, is that, for example, you can insert a Cat into a List<Animal>, but not into a List<Dog>... you can use wildcards to make generics more extensible where possible; for example, reading from a List<Dog> is the similar to reading from a List<Animal> -- but not writing.

The Generics in the Java Language and the Section on Generics from the Java Tutorials have a very good, in-depth explanation as to why some things are or are not polymorphic or permitted with generics.

Gorlin answered 30/4, 2010 at 14:46 Comment(0)
B
50

A point I think should be added to what other answers mention is that while

List<Dog> isn't-a List<Animal> in Java

it is also true that

A list of dogs is-a list of animals in English (under a reasonable interpretation)

The way the OP's intuition works - which is completely valid of course - is the latter sentence. However, if we apply this intuition we get a language that is not Java-esque in its type system: Suppose our language does allow adding a cat to our list of dogs. What would that mean? It would mean that the list ceases to be a list of dogs, and remains merely a list of animals. And a list of mammals, and a list of quadrapeds.

To put it another way: A List<Dog> in Java does not mean "a list of dogs" in English, it means "a list of dogs and nothing other than dogs".

More generally, OP's intuition lends itself towards a language in which operations on objects can change their type, or rather, an object's type(s) is a (dynamic) function of its value.

Bedridden answered 30/3, 2013 at 7:14 Comment(3)
Yes, human language is more fuzzy. But still, once you add a different animal to the list of dogs, it is still a list of animals, but no longer a list of dogs. The difference being, a human, with the fuzzy logic, usually has no problem realizing that.Cookie
As someone who finds the constant comparisons to arrays even more confusing, this answer nailed it for me. My problem was the language intuition.Florenceflorencia
I think the confusion stems from the question of whether the term "list of woozle" refers to a container that may be used to store woozles, a container that holds containers that each hold a woozle, or the contents of a container of woozles, the contents of a container of woozle-containers, or the aggregated contents of the woozle containers held in a collection of them. The English phrase "list of woozles" would most often refer to the last of those, but related constructs in programming languages would often refer to one of the others.Asymptote
S
38

I would say the whole point of Generics is that it doesn't allow that. Consider the situation with arrays, which do allow that type of covariance:

  Object[] objects = new String[10];
  objects[0] = Boolean.FALSE;

That code compiles fine, but throws a runtime error (java.lang.ArrayStoreException: java.lang.Boolean in the second line). It is not typesafe. The point of Generics is to add the compile time type safety, otherwise you could just stick with a plain class without generics.

Now there are times where you need to be more flexible and that is what the ? super Class and ? extends Class are for. The former is when you need to insert into a type Collection (for example), and the latter is for when you need to read from it, in a type safe manner. But the only way to do both at the same time is to have a specific type.

Salyers answered 30/4, 2010 at 14:50 Comment(3)
Arguably, array covariance is a language design bug. Note that due to type erasure, the same behaviour is technically impossible for generic collection.Schuyler
"I would say the whole point of Generics is that it doesn't allow that.". You can never be sure: Java and Scala's Type Systems are Unsound: The Existential Crisis of Null Pointers (presented at OOPSLA 2016) (since corrected it seems)Armilda
Indeed. Reified generics can fundamentally protect against that, but Java's non-type-erased generics cannot. List<Dog> and List<Animal> are both just poor disguises for List, which has zero safety built into it; if you can get around the compile checks (very easy) or create a setup that compile checks cannot be applied to (also easy), you can blow things up.Mazdaism
L
23

To understand the problem it's useful to make comparison to arrays.

List<Dog> is not subclass of List<Animal>.
But Dog[] is subclass of Animal[].

Arrays are reifiable and covariant.
Reifiable means their type information is fully available at runtime.
Therefore arrays provide runtime type safety but not compile-time type safety.

    // All compiles but throws ArrayStoreException at runtime at last line
    Dog[] dogs = new Dog[10];
    Animal[] animals = dogs; // compiles
    animals[0] = new Cat(); // throws ArrayStoreException at runtime

It's vice versa for generics:
Generics are erased and invariant.
Therefore generics can't provide runtime type safety, but they provide compile-time type safety.
In the code below if generics were covariant it will be possible to make heap pollution at line 3.

    List<Dog> dogs = new ArrayList<>();
    List<Animal> animals = dogs; // compile-time error, otherwise heap pollution
    animals.add(new Cat());
Landscape answered 29/9, 2017 at 19:55 Comment(2)
It might be argued that, precisely because of that, Arrays in Java are broken,Cystoid
Arrays being covariant is a compiler "feature".Secundine
K
10

Others have done a decent job of explaining why you cannot just cast a list of descendant to list of superclass.

However, many people visit this question looking for a solution.

So, the solution to this problem since Java version 10 is as follows:

(Note: S = superclass)

List<S> supers = List.copyOf( descendants );

This function will do a cast if it is perfectly safe to do so, or a copy if a cast would not be safe. The resulting list is unmodifiable.

For an in-depth explanation (which takes into consideration the potential pitfalls mentioned by other answers here) see related question and my 2022 answer to it: https://mcmap.net/q/54704/-most-efficient-way-to-cast-list-lt-subclass-gt-to-list-lt-baseclass-gt

Kee answered 11/5, 2022 at 6:10 Comment(1)
I like this because its better than superclassThingList = new Array(subclassOfThingList);Asphodel
C
8

The answers given here didn't fully convince me. So instead, I make another example.

public void passOn(Consumer<Animal> consumer, Supplier<Animal> supplier) {
    consumer.accept(supplier.get());
}

sounds fine, doesn't it? But you can only pass Consumers and Suppliers for Animals. If you have a Mammal consumer, but a Duck supplier, they should not fit although both are animals. In order to disallow this, additional restrictions have been added.

Instead of the above, we have to define relationships between the types we use.

E. g.,

public <A extends Animal> void passOn(Consumer<A> consumer, Supplier<? extends A> supplier) {
    consumer.accept(supplier.get());
}

makes sure that we can only use a supplier which provides us the right type of object for the consumer.

OTOH, we could as well do

public <A extends Animal> void passOn(Consumer<? super A> consumer, Supplier<A> supplier) {
    consumer.accept(supplier.get());
}

where we go the other way: we define the type of the Supplier and restrict that it can be put into the Consumer.

We even can do

public <A extends Animal> void passOn(Consumer<? super A> consumer, Supplier<? extends A> supplier) {
    consumer.accept(supplier.get());
}

where, having the intuitive relations Life -> Animal -> Mammal -> Dog, Cat etc., we could even put a Mammal into a Life consumer, but not a String into a Life consumer.

Castellano answered 14/2, 2015 at 21:26 Comment(1)
Among the 4 versions, #2 is probably incorrect. e.g. we cannot call it with (Consumer<Runnable>, Supplier<Dog>) while Dog is subtype of Animal & RunnableSexpot
S
7

The basis logic for such behavior is that Generics follow a mechanism of type erasure. So at run time you have no way if identifying the type of collection unlike arrays where there is no such erasure process. So coming back to your question...

So suppose there is a method as given below:

add(List<Animal>){
    //You can add List<Dog or List<Cat> and this will compile as per rules of polymorphism
}

Now if java allows caller to add List of type Animal to this method then you might add wrong thing into collection and at run time too it will run due to type erasure. While in case of arrays you will get a run time exception for such scenarios...

Thus in essence this behavior is implemented so that one cannot add wrong thing into collection. Now I believe type erasure exists so as to give compatibility with legacy java without generics....

Squalid answered 4/12, 2012 at 10:43 Comment(0)
B
5

Subtyping is invariant for parameterized types. Even tough the class Dog is a subtype of Animal, the parameterized type List<Dog> is not a subtype of List<Animal>. In contrast, covariant subtyping is used by arrays, so the array type Dog[] is a subtype of Animal[].

Invariant subtyping ensures that the type constraints enforced by Java are not violated. Consider the following code given by @Jon Skeet:

List<Dog> dogs = new ArrayList<Dog>(1);
List<Animal> animals = dogs;
animals.add(new Cat()); // compile-time error
Dog dog = dogs.get(0);

As stated by @Jon Skeet, this code is illegal, because otherwise it would violate the type constraints by returning a cat when a dog expected.

It is instructive to compare the above to analogous code for arrays.

Dog[] dogs = new Dog[1];
Object[] animals = dogs;
animals[0] = new Cat(); // run-time error
Dog dog = dogs[0];

The code is legal. However, throws an array store exception. An array carries its type at run-time this way JVM can enforce type safety of covariant subtyping.

To understand this further let's look at the bytecode generated by javap of the class below:

import java.util.ArrayList;
import java.util.List;

public class Demonstration {
    public void normal() {
        List normal = new ArrayList(1);
        normal.add("lorem ipsum");
    }

    public void parameterized() {
        List<String> parameterized = new ArrayList<>(1);
        parameterized.add("lorem ipsum");
    }
}

Using the command javap -c Demonstration, this shows the following Java bytecode:

Compiled from "Demonstration.java"
public class Demonstration {
  public Demonstration();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return

  public void normal();
    Code:
       0: new           #2                  // class java/util/ArrayList
       3: dup
       4: iconst_1
       5: invokespecial #3                  // Method java/util/ArrayList."<init>":(I)V
       8: astore_1
       9: aload_1
      10: ldc           #4                  // String lorem ipsum
      12: invokeinterface #5,  2            // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
      17: pop
      18: return

  public void parameterized();
    Code:
       0: new           #2                  // class java/util/ArrayList
       3: dup
       4: iconst_1
       5: invokespecial #3                  // Method java/util/ArrayList."<init>":(I)V
       8: astore_1
       9: aload_1
      10: ldc           #4                  // String lorem ipsum
      12: invokeinterface #5,  2            // InterfaceMethod java/util/List.add:(Ljava/lang/Object;)Z
      17: pop
      18: return
}

Observe that the translated code of method bodies are identical. Compiler replaced each parameterized type by its erasure. This property is crucial meaning that it did not break backwards compatibility.

In conclusion, run-time safety is not possible for parameterized types, since compiler replaces each parameterized type by its erasure. This makes parameterized types are nothing more than syntactic sugar.

Bonneau answered 3/5, 2018 at 14:0 Comment(0)
B
4

If you are sure that the list items are subclasses of that given super type, you can cast the list using this approach:

(List<Animal>) (List<?>) dogs

This is usefull when you want to pass the list inside of a constructor or iterate over it.

Blabbermouth answered 28/1, 2016 at 21:11 Comment(2)
This will create more problems than it actually solvesTasteful
If you try to add a Cat to the list, sure it will create problems, but for looping purposes i think its the only non verbose answer.Blabbermouth
A
3

The answer as well as other answers are correct. I am going to add to those answers with a solution that I think will be helpful. I think this comes up often in programming. One thing to note is that for Collections (Lists, Sets, etc.) the main issue is adding to the Collection. That is where things break down. Even removing is OK.

In most cases, we can use Collection<? extends T> rather then Collection<T> and that should be the first choice. However, I am finding cases where it is not easy to do that. It is up for debate as to whether that is always the best thing to do. I am presenting here a class DownCastCollection that can take convert a Collection<? extends T> to a Collection<T> (we can define similar classes for List, Set, NavigableSet,..) to be used when using the standard approach is very inconvenient. Below is an example of how to use it (we could also use Collection<? extends Object> in this case, but I am keeping it simple to illustrate using DownCastCollection.

/**Could use Collection<? extends Object> and that is the better choice. 
* But I am doing this to illustrate how to use DownCastCollection. **/

public static void print(Collection<Object> col){  
    for(Object obj : col){
    System.out.println(obj);
    }
}
public static void main(String[] args){
  ArrayList<String> list = new ArrayList<>();
  list.addAll(Arrays.asList("a","b","c"));
  print(new DownCastCollection<Object>(list));
}

Now the class:

import java.util.AbstractCollection;
import java.util.Collection;
import java.util.Iterator;
import java.util.NoSuchElementException;

public class DownCastCollection<E> extends AbstractCollection<E> implements Collection<E> {
private Collection<? extends E> delegate;

public DownCastCollection(Collection<? extends E> delegate) {
    super();
    this.delegate = delegate;
}

@Override
public int size() {
    return delegate ==null ? 0 : delegate.size();
}

@Override
public boolean isEmpty() {
    return delegate==null || delegate.isEmpty();
}

@Override
public boolean contains(Object o) {
    if(isEmpty()) return false;
    return delegate.contains(o);
}
private class MyIterator implements Iterator<E>{
    Iterator<? extends E> delegateIterator;

    protected MyIterator() {
        super();
        this.delegateIterator = delegate == null ? null :delegate.iterator();
    }

    @Override
    public boolean hasNext() {
        return delegateIterator != null && delegateIterator.hasNext();
    }

    @Override
    public  E next() {
        if(!hasNext()) throw new NoSuchElementException("The iterator is empty");
        return delegateIterator.next();
    }

    @Override
    public void remove() {
        delegateIterator.remove();

    }

}
@Override
public Iterator<E> iterator() {
    return new MyIterator();
}



@Override
public boolean add(E e) {
    throw new UnsupportedOperationException();
}

@Override
public boolean remove(Object o) {
    if(delegate == null) return false;
    return delegate.remove(o);
}

@Override
public boolean containsAll(Collection<?> c) {
    if(delegate==null) return false;
    return delegate.containsAll(c);
}

@Override
public boolean addAll(Collection<? extends E> c) {
    throw new UnsupportedOperationException();
}

@Override
public boolean removeAll(Collection<?> c) {
    if(delegate == null) return false;
    return delegate.removeAll(c);
}

@Override
public boolean retainAll(Collection<?> c) {
    if(delegate == null) return false;
    return delegate.retainAll(c);
}

@Override
public void clear() {
    if(delegate == null) return;
        delegate.clear();

}

}

Aguiar answered 15/12, 2014 at 11:14 Comment(3)
This is a good idea, so much so that it exists in Java SE already. ; ) Collections.unmodifiableCollectionLegman
Right but the collection I define can be modified.Aguiar
Yes, it can be modified. Collection<? extends E> already handles that behavior correctly though, unless you use it in a way that is not type-safe (e.g. casting it to something else). The only advantage I see there is, when you call the add operation, it throws an exception even if you casted it.Cookie
M
2

The issue has been correctly identified as related to variance but the details are not correct. A purely functional list is a covariant data functor, which means if a type Sub is a subtype of Super, then a list of Sub is definitely a subtype of a list of Super.

However mutability of a list is not the basic problem here. The problem is mutability in general. The problem is well known, and is called the Covariance Problem, it was first identified I think by Castagna, and it completely and utterly destroys object orientation as a general paradigm. It is based on previously established variance rules established by Cardelli and Reynolds.

Somewhat oversimplifying, lets consider assignment of an object B of type T to an object A of type T as a mutation. This is without loss of generality: a mutation of A can be written A = f (A) where f: T -> T. The problem, of course, is that whilst functions are covariant in their codomain, they're contravariant in their domain, but with assignments the domain and codomain are the same, so assignment is invariant!

It follows, generalising, that subtypes cannot be mutated. But with object orientation mutation is fundamental, hence object orientation is intrinsically flawed.

Here's a simple example: in a purely functional setting a symmetric matrix is clearly a matrix, it is a subtype, no problem. Now lets add to matrix the ability to set a single element at coordinates (x,y) with the rule no other element changes. Now symmetric matrix is no longer a subtype, if you change (x,y) you have also changed (y,x). The functional operation is delta: Sym -> Mat, if you change one element of a symmetric matrix you get a general non-symmetric matrix back. Therefore if you included a "change one element" method in Mat, Sym is not a subtype. In fact .. there are almost certainly NO proper subtypes.

To put all this in easier terms: if you have a general data type with a wide range of mutators which leverage its generality you can be certain any proper subtype cannot possibly support all those mutations: if it could, it would be just as general as the supertype, contrary to the specification of "proper" subtype.

The fact Java prevents subtyping mutable lists fails to address the real issue: why are you using object oriented rubbish like Java when it was discredited several decades ago??

In any case there's a reasonable discussion here:

https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)

Mekka answered 1/11, 2020 at 4:2 Comment(0)
R
0

Lets take the example from JavaSE tutorial

public abstract class Shape {
    public abstract void draw(Canvas c);
}

public class Circle extends Shape {
    private int x, y, radius;
    public void draw(Canvas c) {
        ...
    }
}

public class Rectangle extends Shape {
    private int x, y, width, height;
    public void draw(Canvas c) {
        ...
    }
}

So why a list of dogs (circles) should not be considered implicitly a list of animals (shapes) is because of this situation:

// drawAll method call
drawAll(circleList);


public void drawAll(List<Shape> shapes) {
   shapes.add(new Rectangle());    
}

So Java "architects" had 2 options which address this problem:

  1. do not consider that a subtype is implicitly it's supertype, and give a compile error, like it happens now

  2. consider the subtype to be it's supertype and restrict at compile the "add" method (so in the drawAll method, if a list of circles, subtype of shape, would be passed, the compiler should detected that and restrict you with compile error into doing that).

For obvious reasons, that chose the first way.

Rostock answered 27/2, 2016 at 13:0 Comment(0)
S
0

We should also take in consideration how the compiler threats the generic classes: in "instantiates" a different type whenever we fill the generic arguments.

Thus we have ListOfAnimal, ListOfDog, ListOfCat, etc, which are distinct classes that end up being "created" by the compiler when we specify the generic arguments. And this is a flat hierarchy (actually regarding to List is not a hierarchy at all).

Another argument why covariance doesn't make sense in case of generic classes is the fact that at base all classes are the same - are List instances. Specialising a List by filling the generic argument doesn't extend the class, it just makes it work for that particular generic argument.

Secundine answered 2/3, 2018 at 7:48 Comment(0)
C
0

The problem has been well-identified. But there's a solution; make doSomething generic:

<T extends Animal> void doSomething<List<T> animals) {
}

now you can call doSomething with either List<Dog> or List<Cat> or List<Animal>.

Counteroffensive answered 28/3, 2018 at 18:56 Comment(1)
Yea, except do something might depend on Dog specific behavior.Asphodel
F
0

another solution is to build a new list

List<Dog> dogs = new ArrayList<Dog>(); 
List<Animal> animals = new ArrayList<Animal>(dogs);
animals.add(new Cat());
Foamy answered 20/7, 2018 at 14:12 Comment(0)
G
0

Further to the answer by Jon Skeet, which uses this example code:

// Illegal code - because otherwise life would be Bad
List<Dog> dogs = new ArrayList<Dog>(); // ArrayList implements List
List<Animal> animals = dogs; // Awooga awooga
animals.add(new Cat());
Dog dog = dogs.get(0); // This should be safe, right?

At the deepest level, the problem here is that dogs and animals share a reference. That means that one way to make this work would be to copy the entire list, which would break reference equality:

// This code is fine
List<Dog> dogs = new ArrayList<Dog>();
dogs.add(new Dog());
List<Animal> animals = new ArrayList<>(dogs); // Copy list
animals.add(new Cat());
Dog dog = dogs.get(0);   // This is fine now, because it does not return the Cat

After calling List<Animal> animals = new ArrayList<>(dogs);, you cannot subsequently directly assign animals to either dogs or cats:

// These are both illegal
dogs = animals;
cats = animals;

therefore you can't put the wrong subtype of Animal into the list, because there is no wrong subtype -- any object of subtype ? extends Animal can be added to animals.

Obviously, this changes the semantics, since the lists animals and dogs are no longer shared, so adding to one list does not add to the other (which is exactly what you want, to avoid the problem that a Cat could be added to a list that is only supposed to contain Dog objects). Also, copying the entire list can be inefficient. However, this does solve the type equivalence problem, by breaking reference equality.

Gleeful answered 20/11, 2019 at 4:21 Comment(0)
L
0

I see that the question has already been answered a number of times, just want to put in my inputs on the same question.

Lets us go ahead and create a simplified Animal class hierarchy.

abstract class Animal {
    void eat() {
        System.out.println("animal eating");
    }
}

class Dog extends Animal {
    void bark() { }
}

class Cat extends Animal {
    void meow() { }
}

Now let us have a look at our old friend Arrays, which we know support polymorphism implicitly-

class TestAnimals {
    public static void main(String[] args) {
        Animal[] animals = {new Dog(), new Cat(), new Dog()};
        Dog[] dogs = {new Dog(), new Dog(), new Dog()};
        takeAnimals(animals);
        takeAnimals(dogs);
    }

    public void takeAnimals(Animal[] animals) {
        for(Animal a : animals) {
            System.out.println(a.eat());
        }
    }   
}

The class compiles fine and when we run the above class we get the output

animal eating
animal eating
animal eating
animal eating
animal eating
animal eating

The point to note here is that the takeAnimals() method is defined to take anything which is of type Animal, it can take an array of type Animal and it can take an array of Dog as well because Dog-is-a-Animal. So this is Polymorphism in action.

Let us now use this same approach with generics,

Now say we tweak our code a little bit and use ArrayLists instead of Arrays -

class TestAnimals {
    public static void main(String[] args) {
        ArrayList<Animal> animals = new ArrayList<Animal>();
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());
        takeAnimals(animals);
    }

    public void takeAnimals(ArrayList<Animal> animals) {
        for(Animal a : animals) {
            System.out.println(a.eat());
        }
    }   
}

The class above will compile and will produce the output -

animal eating
animal eating
animal eating
animal eating
animal eating
animal eating

So we know this works, now lets tweak this class a little bit to use Animal type polymorphically -

class TestAnimals {
    public static void main(String[] args) {
        ArrayList<Animal> animals = new ArrayList<Animal>();
        animals.add(new Dog());
        animals.add(new Cat());
        animals.add(new Dog());

        ArrayList<Dog> dogs = new ArrayList<Dog>();
        takeAnimals(animals);
        takeAnimals(dogs);
    }

    public void takeAnimals(ArrayList<Animal> animals) {
        for(Animal a : animals) {
            System.out.println(a.eat());
        }
    }   
}

Looks like there should be no problem in compiling the above class as the takeAnimals() method is designed to take any ArrayList of type Animal and Dog-is-a-Animal so it should not be a deal breaker here.

But, unfortunately the compiler throws an error and doesn't allow us to pass a Dog ArrayList to a variable expecting Animal ArrayList.

You ask why?

Because just imagine, if JAVA were to allow the Dog ArrayList - dogs - to be put into the Animal ArrayList - animals - and then inside the takeAnimals() method somebody does something like -

animals.add(new Cat());

thinking that this should be doable because ideally it is an Animal ArrayList and you should be in a position to add any cat to it as Cat-is-also-a-Animal, but in real you passed a Dog type ArrayList to it.

So, now you must be thinking the the same should have happened with the Arrays as well. You are right in thinking so.

If somebody tries to do the same thing with Arrays then Arrays are also going to throw an error but Arrays handle this error at runtime whereas ArrayLists handle this error at compile time.

Ladner answered 4/12, 2020 at 15:33 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.