Параметры типа времени компиляции с несколькими границами

В принципе, нет, вы не можете. Концептуальная причина заключается в том, как связаны универсальные типы. Когда вы создаете такой класс, как Zoo<T extends Animal>, Tне означает «любой тип, который расширяет Animal», это означает «конкретный тип, который расширяет Animal, который будет предоставлен во время выполнения». Обычно это позволяет вам делать то, что вы хотите, но ваш случай, похоже, проверяет границы (ba-dum-tiss) этой системы.

Я думаю, что более конкретный ответ должен будет войти в систему привязки подстановочных знаков (?) - что-то в ? extends A & B означает, что он не может доказать, что тип C, который расширяет A & B & D, действительно соответствует.

(Хуже) дизайн, который достигает вашей цели, выглядит так:

  public static abstract class Zoo{
    private List<Animal> animals = new ArrayList<>();

    protected void addAnimalHelper(Animal animal) {
      this.animals.add(animal);
    }
  }

  public static class BirdZoo extends Zoo {
    public <T extends Animal & Bird> void addAnimal(T animal) {
      addAnimalHelper(animal);
    }
  }

  BirdZoo birdZoo = new BirdZoo();
  birdZoo.addAnimal(new Ostrich()); // ok
  birdZoo.addAnimal(new Sparrow()); // ok
  birdZoo.addAnimal(new Meerkat()); // Meekrat doesn't conform to Bird
  birdZoo.addAnimal(new Buffalo()); // Buffalo doesn't conform to Bird

С параметром типа, закодированным в сигнатуре метода, система типов может свободно выбирать новый T при каждом вызове метода, что позволяет ей привязываться к Ostrich при одном вызове и к Sparrow при следующем.

Очевидно, что у этого есть некоторые недостатки по сравнению с желаемым дизайном:

1. Базовое хранилище является «сырым» (в данном случае просто Animal), типизированный подкласс обеспечивает типизацию элементов.
2. Точно так же извлекать элементы из хранилища и сохранять известный тип сложно/запутанно.
3. Требуется шаблонный метод в каждом подклассе + доступ к помощнику для кодирования типов в методах.

Другой вариант, который работает только частично:

  // Note - inheritance isn't used here since it breaks due to method overriding issues.
  public static class BirdZoo<T extends Animal & Bird> {
    private List<T> animals = new ArrayList<>();
    public <X extends Animal & Bird> void addAnimal(X animal) {
      this.animals.add((T)animal); // Unchecked cast warning
    }
    public List<T> getAnimals() {
      return Collections.unmodifiableList(animals);
    }
  }

  BirdZoo<?> wildBirdZoo = new BirdZoo<>();
  wildBirdZoo.addAnimal(new Ostrich()); // ok
  wildBirdZoo.addAnimal(new Sparrow()); // ok
  wildBirdZoo.addAnimal(new Meerkat()); // error - incompatible types
  wildBirdZoo.addAnimal(new Buffalo()); // error - incompatible types

Тот факт, что он жалуется на приведение X к T, указывает на проблему, вокруг которой мы танцуем. Например, когда экземпляр создан с помощью BirdZoo<?>, в основном все в порядке. С другой стороны, представьте, что зоопарк был построен с использованием BirdZoo<Ostrich> и называется ostrichBirdZoo.addAnimal(new Sparrow());. Тогда у нас есть T=Ostrich и X=Sparrow. И T, и X расширяют и Animal, и Bird, но T != X, НО ни статическая, ни проверка типов недостаточно умны, чтобы сказать!

BirdZoo<?> wildBirdZoo = new BirdZoo<>();
wildBirdZoo.addAnimal(new Ostrich()); // ok
wildBirdZoo.addAnimal(new Sparrow()); // ok

BirdZoo<Ostrich> ostrichBirdZoo = new BirdZoo<>();
ostrichBirdZoo.addAnimal(new Ostrich()); // ok
ostrichBirdZoo.addAnimal(new Sparrow()); // ok and doesn't throw at runtime --> Sparrow to Ostrich cast succeeds.

System.out.println(wildBirdZoo.getAnimals());
System.out.println(ostrichBirdZoo.getAnimals()); // Contains a sparrow...?

Что, кажется, полностью нарушает систему типов.

Короче говоря... это может не сработать так, как вы хотите.