Difference Between List, List<>, List<T>, List<E>, and List<Object>

Difference between List, List?, ListT, ListE, and ListObject

1) Correct

2) You can think of that one as "read only" list, where you don't care about the type of the items.Could e.g. be used by a method that is returning the length of the list.

3) T, E and U are the same, but people tend to use e.g. T for type, E for Element, V for value and K for key. The method that compiles says that it took an array of a certain type, and returns an array of the same type.

4) You can't mix oranges and apples. You would be able to add an Object to your String list if you could pass a string list to a method that expects object lists. (And not all objects are strings)

Java Generics: Is there difference between ListE and List??

There is a difference, although it's not intuitive. I recommend reading the java standard tutorial for more details.

Basically, the two are different and incompatible types. List<E> can store objects that extend, subclass, or actually are type E, but it's its own type. You cannot refer to a List<String> from a List<Object> reference, even though you can add a String to a List<Object>.

List<?> means that it's a list reference that can refer to any parameterized reference of it. A List<?> can refer to a List<String> or a List<Integer>. It's most useful when it's bounded by some interface or class. For example, the first method below (adapted from the java standard tutorial) will only take List<Number>, and not anything like List<Double> or List<Integer>.

public static double sumOfList(List<Number> list) {
    double s = 0.0;
    for (Number n : list)
        s += n.doubleValue();
    return s;
}

But the following code using wildcards can take List<Double> or List<Integer>. It's more flexible.

public static double sumOfList(List<? extends Number> list) {
    double s = 0.0;
    for (Number n : list)
        s += n.doubleValue();
    return s;
}

What is the difference between List (of T) and Collection(of T)?

Collection<T> is a customizable wrapper around IList<T>. While IList<T> is not sealed, it doesn't provide any customization points. Collection<T>'s methods are by default delegated to the standard IList<T> methods, but can be easily overridden to do what you want. It is also possible to wireup events inside a Collection<T> that I don't believe could be done with an IList.

In short, it's much easier to extend it after the fact, which could potentially mean a lot less refactoring.

How can I return the difference between two lists?

You can convert them to Set collections, and perform a set difference operation on them.

Like this:

Set<Date> ad = new HashSet<Date>(a);
Set<Date> bd = new HashSet<Date>(b);
ad.removeAll(bd);

Difference between ListObject and List

Ultimately both statements are same. In this case there is no difference since every class in java extends Object.

You'll see the difference , if you take any specific object other than Object.

For ex:

List<String>  vs List

List? or ListObject

Short answer, using List<?> will allow you to accept something like List<String> while using List<Object> won't.

This is discussed in the official generics trail, here and here.

[...] here is a naive attempt at writing it using generics (and the new for loop syntax):

   void printCollection(Collection<Object> c) {
       for (Object e : c) {
           System.out.println(e);
       }
   }

The problem is that this new version is much less useful than the old one. Whereas the old code could be called with any kind of collection as a parameter, the new code only takes Collection<Object>, which, as we've just demonstrated, is not a supertype of all kinds of collections!

So what is the supertype of all kinds of collections? It's written Collection<?> (pronounced "collection of unknown"), that is, a collection whose element type matches anything. It's called a wildcard type for obvious reasons. We can write:

   void printCollection(Collection<?> c) {
       for (Object e : c) {
           System.out.println(e);
       }
   }

and now, we can call it with any type of collection.

Polymorphism: Why use List list = new ArrayList instead of ArrayList list = new ArrayList?

The main reason you'd do this is to decouple your code from a specific implementation of the interface. When you write your code like this:

List list = new ArrayList();  

the rest of your code only knows that data is of type List, which is preferable because it allows you to switch between different implementations of the List interface with ease.

For instance, say you were writing a fairly large 3rd party library, and say that you decided to implement the core of your library with a LinkedList. If your library relies heavily on accessing elements in these lists, then eventually you'll find that you've made a poor design decision; you'll realize that you should have used an ArrayList (which gives O(1) access time) instead of a LinkedList (which gives O(n) access time). Assuming you have been programming to an interface, making such a change is easy. You would simply change the instance of List from,

List list = new LinkedList();

to

List list = new ArrayList();  

and you know that this will work because you have written your code to follow the contract provided by the List interface.

On the other hand, if you had implemented the core of your library using LinkedList list = new LinkedList(), making such a change wouldn't be as easy, as there is no guarantee that the rest of your code doesn't make use of methods specific to the LinkedList class.

All in all, the choice is simply a matter of design... but this kind of design is very important (especially when working on large projects), as it will allow you to make implementation-specific changes later without breaking existing code.

---

Related Topics