List.contains(Object), why?

Question

Possible Duplicate:
What are the reasons why Map.get(Object key) is not (fully) generic
Why do we have contains(Object o) instead of contains(E e)?

As you all can see here, a templated java.util.List of type E has its contains method not templated: it takes an Object instead. Does anyone know why?
in what case would a List<String> return true in myList.contains(new OtherNonString())? If I'm not mistaken, never, unless the object that it's compared to has type E as an ancestor (which in my string example is impossible due to String being final)

Is it only to maintain backwards compatibility with pre-generics versions? am I missing a use-case where it makes sense? if it's just for backwards compatibility, why not deprecate contains(Object) and create a contains(E)?

Edit:
Some of my sub-questions had been answered before. For reference, also check this question

Answer 1

if it's just for backwards compatibility, why not deprecate contains(Object) and create a contains(E)?

Because contains(Object) and contains(E) have the same type erasure (as you can see in this code sample) and hence would cause compilation errors. Also, deprecating methods was not an option, the top priority back then was to make legacy code work.

Answer 2

Because there is no need to have a template here : this would only prevent some tests and if an object isn't of the required class the method would answer false in any case.

It's much simpler to have in your code a simple test checking if the return of the function is a boolean than a test and a try/catch. The few cases where having a type checked at compile time would allow to find a bug aren't worth the overhead.

Answer 3

It's because the method can return true, even if the parameter is of a different type than the list type. More precisely, contains(Object o) will return true if the list contains an element e, so that e.equals(o) is true.

For example, the following code will print true, even if the type of l2 is not allowed in list:

List<ArrayList<String>> list = 
    new ArrayList<ArrayList<String>>();

ArrayList<String> l1 = new ArrayList<String>();
l1.add("foo");

list.add(l1);

LinkedList<String> l2 = new LinkedList<String>();
l2.add("foo");

System.out.println(list.contains(l2));

The reason for this is that the distinct classes ArrayList and LinkedList both inherit the equals implementation from AbstractList, which does not distinguish between different subclasses. Even if two objects don't have a common superclass, it is possible for their equals implementations to mutually recognize each other.

Answer 4

One of the reason could be contains() doesn't alter list, so don't need to enforce for the type.

From the link you have:

Returns true if this list contains the specified element. More formally, returns true if and only if this list contains at least one element e such that (o==null ? e==null : o.equals(e))

Answer 5

Is it only to maintain backwards compatibility with pre-generics versions?

No, that is handled by the type erasure.

It's like that because that method is not required to be type-safe, and doesn't need to return the actual type.

Answer 6

A counter-example:

List<String> strings = Arrays.asList("hello", "world");
Object o = "hello";
System.out.println(strings.contains(o)); // true

If the contains method didn't allow an Object reference as a parameter, It wouldn't be possible to compile the code above. However, the o variable references an instance of a String, which actually is contained in the given list.

The result of contains is determined by the result of Object.equals(Object o) method, which also defines the type of its argument as a general Object, for the very same reason:

String hello = "hello";
Object o = "hello";
System.out.println(hello.equals(o)); // true

Answer 7

Generics in java is implemented with a technique called erasure.

• If no generic type is given the type is being replaced with Object.
• If necessary the java compiler creates type cast to another object if another generic type is being given.
• The compiler also Generate bridge methods to preserve polymorphism in extended generic types.

This is why there are nog generic types during runtime in the compiled bytecode.

for example

public static <T> void printArray ( T [] inputArray ) {
 for ( T element : inputArray )
    System.out.printf("%s ", element) ;

 System.out.println();
}

after erasure is performed by the compiler

public static void printArray ( Object [] inputArray ) {
    for ( Object element : inputArray )
      System.out.printf("%s ", element) ;

 System.out.println();
}

Their is exactly only one copy of this code in memory, which is called for all printArray calls in this example.

The reason why this is done is backwards compatibility. Generics were first introduced in java version 1.5.

In java version < 1.5 you defined a list like this:

List myList = new ArrayList();

and not like this

List<Integer> myList = new ArrayList<Integer>();

To make sure that old code won't break that was already written the compiled class can not contain information about generics.