What is the benefit of using Class instead of Class as a method parameter type?

Question

NB: This is not a duplicate of the question I have already linked to below. I obviously read that question/answer first before posting and did not have my question answered in any form.

This linked question does go into more detail explaining why the generic Class exists. However I don't get an answer specifically to the benefits of Class in my situation.

What does the generic nature of the class Class<T> mean? What is T?

I've written a utility method that accepts a parameter 'cl' of type Class and performs logic by using cl.isInstance(objectInstance) method.

However I've seen example code that declares parameters using the generic wildcard Class<?>.

Why not just use Class without the generic wildcard? Can't Class represent all possible class types including generics? What is the benefit, if any of using Class<?> in my situation?

The accepted answer in an existing related question (see below) does not actually provide a useful answer.

What does Class<?> mean in Java?

Answer 1

The main difference lies in the (self-)documentation of the code to the reader. A variable declared as Class<?> says: “the actual type represented by this Class instance is unknown or not representable at compile-time and I know that”. In contrast the type Class says: “I’m not using Generics here”, perhaps, because you don’t know that Class is generic, or you are a bit sloppy, didn’t understand the difference between Class<?> and Class, or this is very old pre-Generics code.

This has consequences for the code. E.g.

Class<?> unknownType=Object.class;
Class<String> string=unknownType;

produces a compile-time error as you are assigning an explicitly unknown type to a variable declaring a known type.

In contrast

Class nonGenericType=Object.class;
Class<String> string=nonGenericType;

will only produce a (suppressible) warning as you are performing a non-generic, aka unchecked, operation.

Regarding what you can do with a Class object, besides assignments, there is no difference, as, when you use it to create a new instance, the compile-time type of the returned reference will be the most abstract type there is, java.lang.Object, in both cases. Had Class methods receiving arguments related to the type parameter, a difference showed up as you can’t invoke such methods for an unknown type, Class<?> (it would be the same as trying to insert an element into a List<?>) while you could invoke such a method unchecked on a raw Class instance. But since there are no such methods, there’s no difference in functionality between Class<?> and Class.

Still, you should always use Class<?> to be sure that no accidental unchecked operations, like the assignment shown above, happen. If using Class doesn’t produce compiler warnings, you should check how to (re-)enable them. If the compiler silently ignores raw types or unchecked operations, there might be other problems, with other types than Class, hiding somewhere.

Answer 2

The difference between the wildcard type <?> and the raw type in this particular scenario is only whether the compiler will warn you or not. Otherwise they're equivalent, so if for some reason you don't wouldn't want to use the <?> syntax and you didn't care about compiler warnings, you could use the raw type without any problems.

Netbeans not complaining about the raw type is not correct behaviour, and my Eclipse will complain when using a raw Class.

The Class object has distinct usage patterns, which affect whether the type will be a concrete type (seen in method parameters as Class<T> clazz) or the wildcard Class<?>.

The most common form seen in the API is the concrete type, since it allows you to use newInstance() (primarily) in a type-safe way (making all Class<T> objects automatically type-safe factories), such as the following:

public static void List<T> fill(Class<T> clazz, int size) {
    List<T> l = new ArrayList<T>();
    for(int i = 0;i < size; i++)
        l.add(clazz.newInstance());
    return l;
}

So Class<T> is useful, but what about Class<?>? Well, not so much. As indicated at the beginning, it's just required for syntax compliance. The alternative would be to use a concrete T type redundantly.

public void foo(Class<?> clazz) {
    // Do something non-typed, we don't have a type
}

vs.

public <T> void foo(Class<T> clazz) {
    // Do something non-typed, even though we have a type T
}