Difference between ? (wildcard) and Type Parameter in Java

Question

Can somebody explain me what the difference is between these two methods? Are they same? They do look same to me in terms of what they solve. If they are same, why need ??

Method #1, Unbounded

public static void printList(List<?> list) {
    for (Object elem : list)
        System.out.println(elem + " ");
    System.out.println();
}

Method #2, Unbounded:

public static <T> void printList(List<T> list) {
    for (Object elem : list)
        System.out.println(elem + " ");
    System.out.println();
}

Method #1, Bounded

public static void printList(List<? extends Number> list) {
    for (Object elem : list)
        System.out.println(elem + " ");
    System.out.println();
}

Method #2, Bounded:

public static <T extends Number> void printList(List<T> list) {
    for (Object elem : list)
        System.out.println(elem + " ");
    System.out.println();
}

Answer 1

They are the same in that they accept the same parameter types.

However, identifying the type with T (or whatever) lets you refer to the type elsewhere.

Edit: Examples:

Your unbounded examples do not make full use of the capabilities of parameterized types. You have:

public static <T> void printList(List<T> list) {
    for (Object elem : list)
        System.out.println(elem + " ");
    System.out.println();
}

And that's sufficient for that example of printing string representations, but consider this (very contrived, and no error handling):

public static <T> T getSecondItem (List<T> list) {
    T item = list.get(1);
    return item;
}

The return type is T, which allows you to safely do things like this, with compile time type-checking:

class MyClass {
    public void myMethod () { }
}

void somewhere () {
    List<MyClass> items = ...;
    getSecondItem(items).myMethod();
}

A named type also lets you share the same type constraint in multiple places, e.g.:

public <T> int compareLists (List<T> a, List<T> b) {
    ...
}

If you did not name the type, you could not specify the constraint that a and b are the same list type (you could use List<? extends T> for more flexibility).

You also asked "Why do I need ??". The real answer is: You don't. It's mostly for aesthetics, I suppose. Java strives to be a precise and clutter-free language. There are many situations where you simply don't care what type you are referring to. In those cases, you may use ? without cluttering code with unused type parameter declarations.

Answer 2

In your examples, there is absolutely no difference at all. Each will produce the same output.

The best use and interpretation of generics requires that you know the semantics of the type parameter as well as something about the parameter's role. The reason for this is that in a case such as your first example above (unbounded wild card) the semantics are "a list of objects of unknown type" and a "parameter that will produce (not consume) List<?> instances.

The method above simply produces each List<?> object and calls toString() on each. All objects are guaranteed to have a toString() method and so it isn't necessary to know anything at all about the object's type for this purpose. This is exactly why the unbounded wildcard is the best choice for this method parameter: To produce List<?> instances and to call toString() on them, it is not necessary to know anything about the object's type.

Note that if the ? had the same semantics ("a List of objects of unknown type") but a different purpose ("the List would consume objects of unknown type") things would change very, very radically such that it may be inadvisable (or very difficult) to use a wildcard parameter (at least without a helper method to capture the object's type).

It is generally not possible to assert one generic parameter form for all situations. The best form to use (wildcard vs. concrete; bounded vs. unbounded; extends vs. super) depends on both the semantics of the type parameter and what the role of the parameter in the method will be.

Answer 3

As mentioned above, the ? states that the generic code does not require any reference to a type. As pointed in the Java Trails, this could be a class where the properties are independent of any type like the length of a collection.

Another reason for the ? is that it provides syntax for less ambiguity for the case when the generic code only needs behavior provided by class Object. As pointed out above, the parameter type <T> would work, but the fact that T was defined and then never used could suggest that the developer left out something.

So if <T> is dropped because of semantic ambiguity and <?> is not available, then the developer would be tempted to write <Object>. This however does not allow the generic code to be used for any type, just the Object type.

So, <?> is more precise.