List vs List

Question

Why do we lose type safety when using List and not while using List<Object>? Aren't they basically the same thing?

EDIT: I found that the following gives a compilation error

public class TestClass
{
    static void func(List<Object> o, Object s){
        o.add(s);
    }

    public static void main(String[] args){
        func(new ArrayList<String>(), new Integer(1));
    }
}

whereas this doesn't

public class TestClass
{
    static void func(List o, Object s){
        o.add(s);
    }

    public static void main(String[] args){
        func(new ArrayList<String>(), new Integer(1));
    }
}

Why?

The direct answer to why does the second one compile is so that code written before java 5 can be compiled by 5 and later. — Affe, Jul 21 '11 at 22:35

score 7 · Answer 1 · answered Jul 21 '11 at 22:16

List is a list of some type you don't know. It could be a List<String>, List<Integer>, etc.
It's effectively equivalent to List<?>, or List<? extends Object>, except that it doesn't document that fact. It's only supported for backwards compatibility.

List<Object> is a list of Objects. Any object of any type can be put inside it, contrary to a List<String>, for example, which only accepts strings.

So no, they're not the same thing.

Mike Samuel · Accepted Answer · 2011-07-21T22:26:04.083

5

Why do we lose type safety when using List and not while using List<Object>? Aren't they basically the same thing?

No they are not the same thing.

If you are providing an API,

class API {
  static List<Object> getList() { ... }
  static void modifyList(List<Object> l) { ... }
}

and a client uses it improperly

List<Integer> list = API.getList();
API.modifyList(list);
for (Integer i : list) { ... }  // Invalid

then when your API specifies List<Object> they get a compile-time error, but they don't when API.getList() returns a List and API.modifyList(list) takes a List without generic type parameters.

EDIT:

In comments you mentioned changing

void func(List<Object> s, Object c) { s.add(c); }

to

void func(List s, Object c) { s.add(c); }

so that

func(new List<String>(), "");

would work.

That is violating type safety. The type-safe way to do this is

<T> void func(List<? super T> s, T c) { s.add(c); }

which is basically saying that func is a parameterized function that takes a List whose type can be any super class of T, and a value of type T, and adds the value to the list.

edited Jul 21 '11 at 22:26

answered Jul 21 '11 at 22:05

Mike Samuel

118,113
30
216
245

Yes, I found a similar case. The program doesn't compile when i have this: `func(List – Varun Achar Jul 21 '11 at 22:14
Without generic type, the for loop would not compile as well. – user802421 Jul 21 '11 at 22:18
@Varun, a `List` is not a `List – Mike Samuel Jul 21 '11 at 22:23
"The type-safe way to do this is..." It is sufficient to say ` void func(List s, T c) { s.add(c); }` – user102008 Aug 31 '11 at 03:09
@user102008, true. That is not as general though. You cannot then do `List – Mike Samuel Aug 31 '11 at 17:06
@Mike Samuel: Yes you can. Try it. – user102008 Aug 31 '11 at 20:43
@user102008, You're right. The `` in your signature binds to the type-bottom of (`String`, `Object`) which is (`Object`), but in my signature `` binds to `String`. I was mistakenly assuming it would fail because I was assuming `` would be `String` in both cases. – Mike Samuel Aug 31 '11 at 21:57

score 3 · Answer 3 · answered Jul 21 '11 at 22:05

A List<Object> isn't really any more typesafe than a List. However, the Object in the code does imply intent. When someone else looks at it later, they can see that you purposefully chose Object as the type, rather than wondering if you just forgot to put a type or are storing something else and typecasting it elsewhere.

Since code gets read more than it gets written, hints at the intent of the code can be very valuable later on.

score 1 · Answer 4 · answered Jul 21 '11 at 22:04

The reason you have a compiler warning when you use List instead of List<Object> is that when you have a List the compiler doesn't know what type of List it is, so while you could treat it as a List<Object>, the compiler can't ensure that at some other point in the code it wasn't set to reference a List<String> and the type safety of the Generics cannot be checked. That is really the compiler warning here - it is saying it can't help ensure the type safety of the generics, and it won't happen at runtime either (until at some later point there is an actual cast in the code).

score 0 · Answer 5 · answered Jun 22 '20 at 16:07

Type Erasure is one answer and the backward compatibility to pre Java 1.5 and tighter type check in case of first one.

Generics were introduced to the Java language to provide tighter type checks at compile time and to support generic programming. To implement generics, the Java compiler applies type erasure to:

Replace all type parameters in generic types with their bounds or Object if the type parameters are unbounded. The produced bytecode, therefore, contains only ordinary classes, interfaces, and methods. Insert type casts if necessary to preserve type safety. Generate bridge methods to preserve polymorphism in extended generic types. Type erasure ensures that no new classes are created for parameterized types; consequently, generics incur no runtime overhead.

score 0 · Answer 6 · answered Jul 21 '11 at 21:59

For purposes here, you could say they're the same thing. But presumably you almost never actually fill a List with pure instance of Object. They're Strings or something. In this example, List<Object> is technically using generics but not really taking any advantage of it. So, it loses the compile-time type checking of generics.

List vs List

6 Answers6

Linked