Por que o Java Collections não remove métodos genéricos?

Por que Collection.remove (Object o) não é genérico?

Parece que Collection<E>poderia terboolean remove(E o);

Em seguida, quando você tenta remover acidentalmente (por exemplo) em Set<String>vez de cada String individual de um Collection<String>, seria um erro de tempo de compilação em vez de um problema de depuração posteriormente.

Josh Bloch e Bill Pugh se referem a esta edição em Java Puzzlers IV: A ameaça fantasma de referência, Ataque do clone e A vingança da mudança .

Josh Bloch diz (6:41) que eles tentaram gerar o método get do Map, remover o método e outros, mas "simplesmente não funcionou".

Existem muitos programas razoáveis ​​que não poderiam ser gerados se você permitir apenas o tipo genérico da coleção como tipo de parâmetro. O exemplo dado por ele é uma interseção de a Listde Numbers e a Listde Longs.

remove()(in Mape in Collection) não é genérico porque você deve poder passar qualquer tipo de objeto para remove(). O objeto removido não precisa ser do mesmo tipo que o objeto para o qual você passa remove(); requer apenas que sejam iguais. A partir da especificação de remove(), remove(o)remove o objeto ecomo (o==null ? e==null : o.equals(e))está true. Observe que não há nada que exija oe eseja do mesmo tipo. Isso decorre do fato de o equals()método receber um Objectparâmetro as, não apenas do mesmo tipo que o objeto.

Embora possa ser verdade que muitas classes tenham sido equals()definidas para que seus objetos possam ser iguais apenas aos objetos de sua própria classe, esse nem sempre é o caso. Por exemplo, a especificação para List.equals()diz que dois objetos de Lista são iguais se forem Listas e tiverem o mesmo conteúdo, mesmo que sejam implementações diferentes de List. Então, voltando ao exemplo nesta pergunta, é possível ter um Map<ArrayList, Something>e para mim chamar remove()com um LinkedListargumento as e deve remover a chave que é uma lista com o mesmo conteúdo. Isso não seria possível se remove()fosse genérico e restringisse seu tipo de argumento.

Como se o seu parâmetro type for um curinga, você não poderá usar um método de remoção genérico.

Parece-me que me lembro de me deparar com essa questão com o método get (Object) do Map. O método get, nesse caso, não é genérico, embora deva esperar razoavelmente receber um objeto do mesmo tipo que o primeiro parâmetro de tipo. Percebi que se você está passando o Maps com um curinga como o primeiro parâmetro de tipo, não há como extrair um elemento do Map com esse método, se esse argumento for genérico. Os argumentos curinga não podem ser realmente satisfeitos, porque o compilador não pode garantir que o tipo esteja correto. Especulo que o motivo pelo qual adicionar é genérico é que você deve garantir que o tipo esteja correto antes de adicioná-lo à coleção. No entanto, ao remover um objeto, se o tipo estiver incorreto, ele não corresponderá a nada.

Provavelmente não expliquei muito bem, mas me parece lógico o suficiente.

Além das outras respostas, há outro motivo pelo qual o método deve aceitar um Object, que é predicado. Considere o seguinte exemplo:

class Person {
    public String name;
    // override equals()
}
class Employee extends Person {
    public String company;
    // override equals()
}
class Developer extends Employee {
    public int yearsOfExperience;
    // override equals()
}

class Test {
    public static void main(String[] args) {
        Collection<? extends Person> people = new ArrayList<Employee>();
        // ...

        // to remove the first employee with a specific name:
        people.remove(new Person(someName1));

        // to remove the first developer that matches some criteria:
        people.remove(new Developer(someName2, someCompany, 10));

        // to remove the first employee who is either
        // a developer or an employee of someCompany:
        people.remove(new Object() {
            public boolean equals(Object employee) {
                return employee instanceof Developer
                    || ((Employee) employee).company.equals(someCompany);
        }});
    }
}

O ponto é que o objeto que está sendo passado para o removemétodo é responsável por definir o equalsmétodo. A construção de predicados se torna muito simples dessa maneira.

Suponha que tem uma coleção de Cat, e algumas referências de objetos de tipos Animal, Cat, SiameseCat, e Dog. Perguntar à coleção se ela contém o objeto referido pela referência Catou SiameseCatparece razoável. Perguntar se ele contém o objeto referido pela Animalreferência pode parecer desonesto, mas ainda é perfeitamente razoável. O objeto em questão pode, afinal, ser um Cate pode aparecer na coleção.

Além disso, mesmo que o objeto seja algo diferente de a Cat, não há problema em dizer se ele aparece na coleção - simplesmente responda "não, não aparece". Uma coleção "de estilo de pesquisa" de algum tipo deve ser capaz de aceitar significativamente a referência de qualquer supertipo e determinar se o objeto existe na coleção. Se a referência do objeto passado for de um tipo não relacionado, não há como a coleção a conter, de modo que a consulta não é significativa (de certo modo, ela sempre responderá "não"). No entanto, como não há como restringir os parâmetros a subtipos ou supertipos, é mais prático simplesmente aceitar qualquer tipo e responder "não" a objetos cujo tipo não esteja relacionado ao da coleção.

Eu sempre achei que isso acontecia porque remove () não tem motivos para se importar com o tipo de objeto que você atribui a ele. Independentemente disso, é fácil verificar se esse objeto é um dos que a coleção contém, pois pode chamar igual () em qualquer coisa. É necessário verificar o tipo em add () para garantir que ele contenha apenas objetos desse tipo.

Foi um compromisso. Ambas as abordagens têm sua vantagem:

• remove(Object o)
  • é mais flexível. Por exemplo, ele permite percorrer uma lista de números e removê-los de uma lista de longos.
  • código que usa essa flexibilidade pode ser mais facilmente gerado
• remove(E e) traz mais segurança de tipo ao que a maioria dos programas deseja, detectando erros sutis no tempo de compilação, como tentar erroneamente remover um número inteiro de uma lista de curtos.

A compatibilidade com versões anteriores sempre foi um dos principais objetivos ao desenvolver a API Java; portanto, o remove (Object o) foi escolhido porque facilitava a geração do código existente. Se a compatibilidade com versões anteriores NÃO tivesse sido um problema, acho que os designers escolheriam remover (E e).

Remove não é um método genérico, de modo que o código existente usando uma coleção não genérica ainda será compilado e ainda terá o mesmo comportamento.

Consulte http://www.ibm.com/developerworks/java/library/j-jtp01255.html para obter detalhes.

Edit: Um comentarista pergunta por que o método add é genérico. [... removeu minha explicação ...] O segundo comentarista respondeu à pergunta do firebird84 muito melhor do que eu.

Outro motivo é por causa das interfaces. Aqui está um exemplo para mostrá-lo:

public interface A {}

public interface B {}

public class MyClass implements A, B {}

public static void main(String[] args) {
   Collection<A> collection = new ArrayList<>();
   MyClass item = new MyClass();
   collection.add(item);  // works fine
   B b = item; // valid
   collection.remove(b); /* It works because the remove method accepts an Object. If it was generic, this would not work */
}

Porque isso quebraria o código existente (pré-Java5). por exemplo,

Set stringSet = new HashSet();
// do some stuff...
Object o = "foobar";
stringSet.remove(o);

Agora, você pode dizer que o código acima está errado, mas suponha que o tenha vindo de um conjunto heterogêneo de objetos (ou seja, continha cadeias, número, objetos etc.). Você deseja remover todas as correspondências, o que era legal porque remove iria ignorar as não-seqüências de caracteres porque eram diferentes. Mas se você remover (String o), isso não funcionará mais.