реализации интерфейса с помощью метода аргумента Суперклассов

Question

В качестве практического примера общего вопроса в теме, я хотел бы реализовать метод containsAll в интерфейсе Set с

public boolean containsAll(Iterable<?> c) { /* ... */ } 

Я полагаю, это должно быть разрешено, так как Collection - Iterable, что означает, что containsAll будет охватывать требования к интерфейсу. Точно так же, в более общем плане возможность реализации интерфейсов с суперклассами аргументов кажется, что она должна работать.

Однако Eclipse не говорит (не пробовал просто джавак прямо) - может кто-нибудь объяснить причину этого? Я уверен, что есть что-то в спецификации, которая делает это так, как есть, но я хотел бы также понять мотивацию требования. Или я пропустил что-то вроде Iterable<?>, не являясь суперклассом Collection<?>?

В качестве побочного вопроса - учитывая, что я объявляю два метода, метод с сигнатурой Iterable всегда будет предпочтительнее при вызовах с аргументом Collection?

Затмение Ошибка:

Если удалить метод с Collection подписи, просто оставить Iterable один (см после ошибки), я получаю следующее:

The type BitPowerSet must implement the inherited abstract method Set<Long>.containsAll(Collection<?>)

Конкретная реализация бытия :

@Override public boolean containsAll(Collection<?> c) { 
    for (Object o : c) if (!contains(o)) return false; 
    return true; 
} 
public boolean containsAll(Iterable<?> c) { 
    for (Object o : c) if (!contains(o)) return false; 
    return true; 
} 

Answer 1

Моя догадка, почему Java имеет такое ограничение есть, скажем, у вас есть:

class A { 
    void foo(String s) { ... } 
} 

class B extends A { 
    // Note generalized type 
    @Override void foo(Object s) { ... } 
} 

Теперь, если у вас есть class C extends B и он хочет, чтобы переопределить foo, не ясно, какой аргумент он должен принять.

Скажет, например, C продлил непосредственно на первом, перекрывая void foo(String s), а затем он был изменен, чтобы расширить B. В этом случае C Существующего переопределение foo станет недействительным, поскольку Б foo должен иметь возможность обрабатывать все Object с, не только String s.

Answer 2

Поскольку интерфейс, который вы реализуете, объявляет (аннотация) метод containsAll(Collection<?>), вы должны реализовать его с помощью этой точной подписи. Java не позволяет вам реализовать/переопределить метод с более широким типом параметра, чем оригинал. Вот почему вы получаете сообщение об ошибке, когда вы закомментируете свой метод с помощью подписи Collection.

Вы не показываете другую ошибку, о которой вы заявляете, чтобы получить, когда метод не закомментирован, но, я думаю, это могло бы что-то сделать с неоднозначной перегрузкой метода.

Answer 3

Типы аргументов являются частью сигнатуры метода, поэтому jvm нуждается в методе с точной одной и той же сигнатурой для поиска переопределений. A containsAll (Iterable) будет иметь другую подпись, чем containsAll (Collection).

Если я правильно помню, компилятор должен использовать некоторые обходные пути, чтобы заставить дженерики работать, несмотря на это ограничение.

К вашему второму вопросу компилятор предпочтет аргумент Collection, поскольку он является подтипом Iterable, что делает метод Collection более конкретным, чем Iterable.