另一个解决方案是建立一个新的列表

List<Dog> dogs = new ArrayList<Dog>(); 
List<Animal> animals = new ArrayList<Animal>(dogs);
animals.add(new Cat());

关于Jon Skeet的回答，他使用了以下示例代码：

// 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?

在最深层次上，这里的问题是狗和动物共享一个参考。这意味着一种方法是复制整个列表，这将打破引用相等：

// 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

在调用List＜Animal＞animals＝new ArrayList＜＞（狗）；后；，您随后不能将动物直接分配给狗或猫：

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

因此，您不能将错误的Animal子类型放入列表中，因为没有错误的子类型--任何子类型的对象？扩展动物可以添加到动物。

显然，这改变了语义，因为动物和狗的列表不再共享，所以添加到一个列表不会添加到另一个列表中（这正是您想要的，以避免将猫添加到只应包含狗对象的列表中的问题）。此外，复制整个列表可能效率低下。然而，通过打破引用相等性，这确实解决了类型等价问题。

让我们以JavaSE教程为例

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) {
        ...
    }
}

因此，为什么狗（圆圈）的列表不应被视为动物（形状）的列表，是因为这种情况：

// drawAll method call
drawAll(circleList);


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

因此，Java“架构师”有两个选项可以解决这个问题：

不要认为子类型是隐式的，它是父类型，并给出编译错误，就像现在发生的那样将子类型视为它的父类型，并在编译“add”方法时进行限制（因此在drawAll方法中，如果要传递圆的列表（形状的子类型），编译器应该检测到这一点，并用编译错误限制您这样做）。

出于明显的原因，他们选择了第一条路。

这里给出的答案并不能完全说服我，所以我再举一个例子。

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

听起来不错，不是吗？但你只能通过动物消费者和供应商。如果你有哺乳动物的消费者，但鸭子的供应商，尽管它们都是动物，但它们不应该适合。为了禁止这种行为，增加了额外的限制。

我们必须定义我们使用的类型之间的关系，而不是上述内容。

例如。，

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

确保我们只能使用为消费者提供正确类型对象的供应商。

OTOH，我们也可以

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

我们的方向相反：我们定义供应商的类型，并限制其可以投放给消费者。

我们甚至可以做到

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

其中，有了“生活”->“动物”->“哺乳动物”->“狗”、“猫”等直观关系，我们甚至可以将“哺乳动物”放入“生活”消费者，但不能将“字符串”放入“生命”消费者。

如果您确定列表项是给定超类型的子类，则可以使用以下方法强制转换列表：

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

当您想要在构造函数内部传递列表或对其进行迭代时，这是非常有用的。

问题已正确识别为与差异有关，但详细信息不正确。纯函数列表是协变数据函子，这意味着如果Sub类型是Super的子类型，那么Sub列表绝对是Super列表的子类型。

然而，列表的可变性并不是这里的基本问题。问题是总体上的可变性。这个问题是众所周知的，被称为协方差问题，我认为它是卡斯塔尼亚首先发现的，它完全彻底地破坏了作为一个通用范式的对象定向。这是基于Cardelli和Reynolds之前建立的方差规则。

有点过于简单化，让我们将T型对象B分配给T型对象A作为突变。这不失一般性：a的突变可以写成a=f（a），其中f:T->T。当然，问题是，虽然函数在其共域中是协变的，但它们在其域中是逆变的，但通过赋值，域和共域是相同的，因此赋值是不变的！

因此，概括而言，亚型不能突变。但是对象定向突变是根本的，因此对象定向本质上是有缺陷的。

这里有一个简单的例子：在纯函数设置中，对称矩阵显然是一个矩阵，它是一个子类型，没有问题。现在，让我们在矩阵中添加一项功能，即在坐标（x，y）处设置一个元素，规则是其他元素不变。现在对称矩阵不再是一个子类型，如果你改变了（x，y），你也改变了（y，x）。函数运算是delta:Sym->Mat，如果你改变对称矩阵的一个元素，你会得到一个一般的非对称矩阵。因此，如果在Mat中包含“更改一个元素”方法，Sym不是子类型。事实上几乎肯定没有合适的亚型。

简单地说，如果你有一个通用的数据类型，其中包含大量的变异器，这些变异器利用了它的通用性，你可以确定任何适当的子类型都不可能支持所有这些变异：如果可以，它将与超类型一样通用，与“适当”子类型的规范相反。

事实上，Java阻止了可变列表的子类型化，这并不能解决真正的问题：几十年前，当Java受到质疑时，为什么要使用面向对象的垃圾呢？？

无论如何，这里有一个合理的讨论：

https://en.wikipedia.org/wiki/Covariance_and_contravariance_（计算机科学）