Is List Dog a subclass of List Animal Why are Java generics not implicitly polymorphic

Question

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 lt Animal gt  animals   By all the rules of inheritance and polymorphism  I would assume that a List lt Dog gt  is a List lt Animal gt  and a List lt Cat gt  is a List lt Animal gt  - 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 lt   extends Animal gt  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

User · Answer

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 lt Animal gt  could be replaced with List lt Dog gt    The problem is that covariance is not safe for mutable lists in general   Suppose you have a List lt Dog gt   and it is being used as a List lt Animal gt    What happens when you try to add a Cat to this List lt Animal gt  which is really a List lt Dog gt    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

User · Answer

The problem has been well-identified  But there s a solution  make doSomething generic    lt T extends Animal gt  void doSomething lt List lt T gt  animals        now you can call doSomething with either List lt Dog  or List lt Cat  or List lt Animal

User · Answer

A point I think should be added to what other answers mention is that while  List lt Dog gt  isn t-a List lt Animal gt  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 lt Dog gt  in Java does not mean  quot a list of dogs quot  in English  it means  quot a list which can have dogs  and nothing else quot   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

User · Answer

If you are sure that the list items are subclasses of that given super type  you can cast the list using this approach   List lt Animal gt    List lt   gt   dogs  This is usefull when you want to pass the list inside of a constructor or iterate over it

User · Answer

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 lt Animal gt          You can add List lt Dog or List lt Cat gt  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

User · Answer

The answers given here didn t fully convince me  So instead  I make another example   public void passOn Consumer lt Animal gt  consumer  Supplier lt Animal gt  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  lt A extends Animal gt  void passOn Consumer lt A gt  consumer  Supplier lt   extends A gt  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  lt A extends Animal gt  void passOn Consumer lt   super A gt  consumer  Supplier lt A gt  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  lt A extends Animal gt  void passOn Consumer lt   super A gt  consumer  Supplier lt   extends A gt  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

User · Answer

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 - gt  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 - gt  Mat  if you change one element of a symmetric matrix you get a general non-symmetric matrix back  Therefore if you included a  quot change one element quot  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  quot proper quot  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

User · Answer

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 lt   extends T gt  rather then Collection lt T gt  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 lt   extends T gt  to a Collection lt T gt   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 lt   extends Object gt  in this case  but I am keeping it simple to illustrate using DownCastCollection      Could use Collection lt   extends Object gt  and that is the better choice     But I am doing this to illustrate how to use DownCastCollection       public static void print Collection lt Object gt  col         for Object obj   col       System out println obj           public static void main String   args     ArrayList lt String gt  list   new ArrayList lt  gt       list addAll Arrays asList  a   b   c       print new DownCastCollection lt Object gt  list        Now the class   import java util AbstractCollection  import java util Collection  import java util Iterator  import java util NoSuchElementException   public class DownCastCollection lt E gt  extends AbstractCollection lt E gt  implements Collection lt E gt    private Collection lt   extends E gt  delegate   public DownCastCollection Collection lt   extends E gt  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 lt E gt       Iterator lt   extends E gt  delegateIterator       protected MyIterator             super            this delegateIterator   delegate    null   null  delegate iterator                Override     public boolean hasNext             return delegateIterator    null  amp  amp  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 lt E gt  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 lt   gt  c        if delegate  null  return false      return delegate containsAll c       Override public boolean addAll Collection lt   extends E gt  c        throw new UnsupportedOperationException        Override public boolean removeAll Collection lt   gt  c        if delegate    null  return false      return delegate removeAll c       Override public boolean retainAll Collection lt   gt  c        if delegate    null  return false      return delegate retainAll c       Override public void clear         if delegate    null  return          delegate clear

User · Answer

Subtyping is invariant for parameterized types  Even tough the class Dog is a subtype of Animal  the parameterized type List lt Dog gt  is not a subtype of List lt Animal gt   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 lt Dog gt  dogs   new ArrayList lt Dog gt  1   List lt Animal gt  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 lt String gt  parameterized   new ArrayList lt  gt  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   lt init gt     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   lt init gt    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   lt init gt    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

User · Answer

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  quot animal eating quot             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 lt Animal gt  animals   new ArrayList lt Animal gt             animals add new Dog             animals add new Cat             animals add new Dog             takeAnimals animals              public void takeAnimals ArrayList lt Animal gt  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 lt Animal gt  animals   new ArrayList lt Animal gt             animals add new Dog             animals add new Cat             animals add new Dog              ArrayList lt Dog gt  dogs   new ArrayList lt Dog gt             takeAnimals animals           takeAnimals dogs              public void takeAnimals ArrayList lt Animal gt  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

User · Answer

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

User · Answer

The reason a List lt Dog gt  is not a List lt Animal gt   is that  for example  you can insert a Cat into a List lt Animal gt   but not into a List lt Dog gt     you can use wildcards to make generics more extensible where possible  for example  reading from  a List lt Dog gt  is the similar to reading from a List lt Animal gt  -- 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

User · Answer

Actually you can use an interface to achieve what you want   public interface Animal       String getName        String getVoice      public class Dog implements Animal       Override      String getName   return  Dog         Override     String getVoice   return  woof          you can then use the collections using  List  lt Animal gt  animalGroup   new ArrayList lt Animal gt     animalGroup add new Dog

User · Answer

another solution is to build a new list  List lt Dog gt  dogs   new ArrayList lt Dog gt      List lt Animal gt  animals   new ArrayList lt Animal gt  dogs   animals add new Cat

User · Answer

No  a List lt Dog gt  is not a List lt Animal gt   Consider what you can do with a List lt Animal gt  - 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 lt Dog gt  dogs   new ArrayList lt Dog gt        ArrayList implements List List lt Animal gt  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 lt   extends Animal gt  because you don t know it s a List lt Cat gt   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 lt   super Animal gt  - 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 lt Object gt

User · Answer

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 lt Shape gt  shapes       shapes add new Rectangle             So Java  architects  had 2 options which address this problem    do not consider that a subtype is implicitly it s supertype  and give a compile error  like it happens now 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

User · Answer

Further to the answer by Jon Skeet  which uses this example code      Illegal code - because otherwise life would be Bad List lt Dog gt  dogs   new ArrayList lt Dog gt        ArrayList implements List List lt Animal gt  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 lt Dog gt  dogs   new ArrayList lt Dog gt     dogs add new Dog     List lt Animal gt  animals   new ArrayList lt  gt  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 lt Animal gt  animals   new ArrayList lt  gt  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

User · Answer

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

User · Answer

To understand the problem it s useful to make comparison to arrays   List lt Dog gt  is not subclass of List lt Animal gt   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 lt Dog gt  dogs   new ArrayList lt  gt         List lt Animal gt  animals   dogs     compile-time error  otherwise heap pollution     animals add new Cat

[java] Is List<Dog> a subclass of List<Animal>? Why are Java generics not implicitly polymorphic?

Examples related to java

Examples related to generics

Examples related to inheritance

Examples related to polymorphism