Why isn't Collection.remove(Object o) generic?
Seems like Collection<E> could have boolean remove(E o);
Then, when you accidentally try to remove (for example) Set<String> instead of each individual String from a Collection<String>, it would be a compile time error instead of a debugging problem later.
remove() (in Map as well as in Collection) is not generic because you should be able to pass in any type of object to remove(). The object removed does not have to be the same type as the object that you pass in to remove(); it only requires that they be equal. From the specification of remove(), remove(o) removes the object e such that (o==null ? e==null : o.equals(e)) is true. Note that there is nothing requiring o and e to be the same type. This follows from the fact that the equals() method takes in an Object as parameter, not just the same type as the object.
Although, it may be commonly true that many classes have equals() defined so that its objects can only be equal to objects of its own class, that is certainly not always the case. For example, the specification for List.equals() says that two List objects are equal if they are both Lists and have the same contents, even if they are different implementations of List. So coming back to the example in this question, it is possible to have a Map<ArrayList, Something> and for me to call remove() with a LinkedList as argument, and it should remove the key which is a list with the same contents. This would not be possible if remove() were generic and restricted its argument type.
equals() method as well ? I could see more benefits to type safety instead of this "libertarian" approach. I think most cases with current implementation are for bugs getting into our code rather than about joyfulness this flexibility that the remove() method brings.
equals() method"?T must be declared as a type parameter on the class, and Object doesn't have any type parameters. There is no way to have a type that refers to "the declaring class".
Equality<T> with equals(T other). Then you could have remove(Equality<T> o) and o is just some object that can be compared to another T.Josh Bloch and Bill Pugh refer to this issue in Java Puzzlers IV: The Phantom Reference Menace, Attack of the Clone, and Revenge of The Shift.
Josh Bloch says (6:41) that they attempted to generify the get method of Map, remove method and some other, but "it simply didn't work".
There are too many reasonable programs that could not be generified if you only allow the generic type of the collection as parameter type. The example given by him is an intersection of a List of Numbers and a List of Longs.
Because if your type parameter is a wildcard, you can't use a generic remove method.
I seem to recall running into this question with Map's get(Object) method. The get method in this case isn't generic, though it should reasonably expect to be passed an object of the same type as the first type parameter. I realized that if you're passing around Maps with a wildcard as the first type parameter, then there's no way to get an element out of the Map with that method, if that argument was generic. Wildcard arguments can't really be satisfied, because the compiler can't guarantee that the type is correct. I speculate that the reason add is generic is that you're expected to guarantee that the type is correct before adding it to the collection. However, when removing an object, if the type is incorrect then it won't match anything anyway. If the argument were a wildcard the method would simply be unusable, even though you may have an object which you can GUARANTEE belongs to that collection, because you just got a reference to it in the previous line....
I probably didn't explain it very well, but it seems logical enough to me.
Assume one has a collection of Cat, and some object references of types Animal, Cat, SiameseCat, and Dog. Asking the collection whether it contains the object referred to by the Cat or SiameseCat reference seems reasonable. Asking whether it contains the object referred to by the Animal reference may seem dodgy, but it's still perfectly reasonable. The object in question might, after all, be a Cat, and might appear in the collection.
Further, even if the object happens to be something other than a Cat, there's no problem saying whether it appears in the collection--simply answer "no, it doesn't". A "lookup-style" collection of some type should be able to meaningfully accept reference of any supertype and determine whether the object exists within the collection. If the passed-in object reference is of an unrelated type, there's no way the collection could possibly contain it, so the query is in some sense not meaningful (it will always answer "no"). Nonetheless, since there isn't any way to restrict parameters to being subtypes or supertypes, it's most practical to simply accept any type and answer "no" for any objects whose type is unrelated to that of the collection.
Comparable is parameterized for the types you can compare with). Then it would not be reasonable to allow people to pass something of an unrelated type.
A and B of one type, and X and Y of another, such that A>B, and X>Y. Either A>Y and Y<A, or X>B and B<X. Those relationships can only exist if the magnitude comparisons know about both types. By contrast, an object's equality comparison method can simply declare itself unequal to anything of any other type, without having to know anything whatsoever about the other type in question. An object of type Cat may have no idea whether it's...FordMustang, but it should have no difficulty saying whether it's equal to such an object (the answer, obviously, being "no").In addition to the other answers, there is another reason why the method should accept an Object, which is predicates. Consider the following sample:
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); }}); } } The point is that the object being passed to the remove method is responsible for defining the equals method. Building predicates becomes very simple this way.
Since Java 8, however, this kind of usage has been superseded by the method removeIf.
yourObject.equals(developer), as documented in the Collections API: java.sun.com/javase/6/docs/api/java/util/…
equals method, namely symmetry. The remove method is only bound to its specification as long as your objects are fulfilling the equals/hashCode spec, so any implementation would be free to do the comparison the other way around. Also, your predicate object does not implement the .hashCode() method (can't implement consistently to equals), thus the remove call will never work on a Hash-based collection (like HashSet or HashMap.keys()). That it works with ArrayList is pure luck.Collection.remove, without breaking its contract (if the ordering is consistent to equals). And a varied ArrayList (or AbstractCollection, I think) with the equals call turned around would still correctly implement the contract - it is your fault if it does not work as intended, since you are breaking the equals contract.
I always figured this was because remove() has no reason to care what type of object you give it. It's easy enough, regardless, to check if that object is one of the ones the Collection contains, since it can call equals() on anything. It's necessary to check type on add() to ensure that it only contains objects of that type.
It was a compromise. Both approaches have their advantage:
remove(Object o) remove(E e) brings more type safety to what most programs want to do by detecting subtle bugs at compile time, like mistakenly trying to remove an integer from a list of shorts.Backwards compatibility was always a major goal when evolving the Java API, therefore remove(Object o) was chosen because it made generifying existing code easier. If backwards compatibility had NOT been an issue, I'm guessing the designers would have chosen remove(E e).
Remove is not a generic method so that existing code using a non-generic collection will still compile and still have the same behavior.
See http://www.ibm.com/developerworks/java/library/j-jtp01255.html for details.
Edit: A commenter asks why the add method is generic. [...removed my explanation...] Second commenter answered the question from firebird84 much better than me.
Another reason is because of interfaces. Here is an example to show it :
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 */ } 
remove() is not covariant. The question, though, is whether this should be allowed. ArrayList#remove() works by way of value equality, not reference equality. Why would you expect that a B would be equal to an A? In your example, it can be, but it's an odd expectation. I'd rather see you supply a MyClass argument here.Because it would break existing (pre-Java5) code. e.g.,
Set stringSet = new HashSet(); // do some stuff... Object o = "foobar"; stringSet.remove(o); Now you might say the above code is wrong, but suppose that o came from a heterogeneous set of objects (i.e., it contained strings, number, objects, etc.). You want to remove all the matches, which was legal because remove would just ignore the non-strings because they were non-equal. But if you make it remove(String o), that no longer works.
