Why method with argument List<Object> can not accept a list of any type like List<A> as argument in java?

Suppose we have a method void m0(List<Object> lst), why can't we call it with an integer list List<Integer> iLst = new ArrayList(); m0(iLst); while with method void m0(Object a), m0(1); is OK. Logically a list of Integer is a list of object, why m0(iLst); is not correct?

There's this thing called variance.

Let's use some types we are all familiar with:

java.lang.Integer extends java.lang.Number extends java.lang.Object *

Covariance

In a covariant system, you can write:

Number x = new Integer();

but you cannot write:

Integer y = new Number();

As you might surmise, basic assignment and such in java is all covariant.

Makes sense, right? Whatever I can do to a reference to a Number instance, I can do to an Integer instance, such as invoking .intValue() on it. But in reverse it does not hold; Integer may have methods that Number doesn't.

Therefore, as you're familiar with, basic java assignment, parameter passing etc is covariant.

Contravariance

In a contravariant system, you cannot write:

Number x = new Integer();

but on the flipside, this actually works:

Integer y = new Number();

Invariance

This is the inflexible one; in this one, neither works. The only thing you can do is:

Integer y = new Integer();

Okay, so, what about generics?

Whereas java is covariant for basic stuff, generics isn't. Generics is contravariant, or covariant, or invariant, depending on how you write the generics.

• Covariant: List<? extends Number> list = new ArrayList<Integer>(); // legal
• Contravariant: List<? super Integer> list = new ArrayList<Number>(); // legal
• Invariant: List<Integer> list = new ArrayList<Integer>(); // only integer will do here

With void m0(List<Object> list), you've picked invariant. For the generics part, only <Object> will do (and for the List part, that is covariant as 'normal' java is, so an ArrayList<Object> can be passed here, but e.g. a List<String> cannot).

Um, wtf? Why???

Because... life. That is how real life works.

Imagine it did not. I can do this, then, and break everything:

List<Integer> ints = new ArrayList<Integer>();
List<Number> numbers = ints; // MARK THIS LINE!
numbers.add(new Double(5.0));
Integer x = ints.get(0); // ERROR!

In the above, if it had compiled and run, the last line would be an error, as the .get(0) call would retrieve a double value which isn't an integer. Fortunately, the above does not compile; the error occurs on the marked line. That's.. because the compiler should disallow this. Generics by its very nature are invariant.

Now, covariance can exist. For example, if you have a method that will sum up the result of invoking .intValue() on each of the Numbers inside, then you could write:

public int sumAll(List<Number> list) {
   int result = 0;
   for (Number n : list) result += n.intValue();
   return result;
}

but that's a bad way to write it; you've decreed that the parameter is invariant, thus, you cannot pass a List<Integer> to this thing. But the code is covariant. It would work just as well if you pass a list of integers. So, you should write that as public int sumAll(List<? extends Number> numbers) instead.

Here is an example of invariance:

public void addSumToEnd(List<Number> list) {
    int sum = 0;
    for (Number n : list) sum += n.intValue();
    list.add(sum);
}

Because we're adding a number here, you couldn't write List<? extends Number>. After all, we're adding an int and you can't do that to a List<Double>. The only acceptable lists you can feed in here are List<Number> and List<Integer> and there's no way to express that in java.

For lists, it's easy: "contravariance = adds" (.add(), .addAll(), etc), "covariance = reads", "invariance = does both". For other generified types it may not be that simple.

Presumably if your m0 method class will only ever 'read', then you can make it covariant, and write:

public m0(List<?> lst) {...}

and <?> is just short for <? extends Object>. You've denied yourself the ability to call .add, but you can still call .get, and crucially you can pass List<String> to such a method, whereas you cannot if it read List<Object> (but, on the other hand, you can call .add() on a List<Object> parameter, and add whatever you like!

*) These are real types in java, but Number is abstract. For the purposes of this example, assume it is not, and that they all have no-args constructors. The point is the type relation, not anything particular about these types.