java-patterns | : star : : fire : Java | Application Framework library

I don't think it's possible to achieve the degree of type safety you aim at.

Let's distinguish compile time and run time.

At compile time, the compiler checks whether the type of clazz matches the consumer's type parameter T. But that doesn't work well with types T that themselves have generics type parameters, e.g. List, as there is no List.class syntax in Java. So, here the best you can do is cast the List.class to Class>.

The object obj that gets operated upon in your function isn't visible in the method's signature, so at compile time there's no chance to check whether its type matches the consumer.

There's nothing stopping you from calling function(String.class, stringConsumer) and having an Integer object. There's no chance the compiler will detect that mistake.

At run time, there is no generics information. That concept is called "type erasure". So, something that at compile time appears as a List, at runtime is just a List.

As at compile time, the obj is not visible at the function invocation, you moved the type check to run time, using the Class.cast() method.

If at compile time your obj is a List, a List, or a List, at run time it's just a raw List without parameters, and the class you are checking against also is just the raw List.class, without any type parameters. The cast() method will accept all these different lists.

So, at run time there's no way to reject a List from entering a consumer expecting a List. You'll probably get a ClassCastException later when the consumer accesses the list elements.

If you want to guard against mismatch of parameterized types, you can only do so at compile time, and to make that possible you have to bring object and consumer into the same syntactic context, probably meaning a big refactoring.

At run time, you can only guard against mismatch of raw types. If you want to do that, it forces you to use some ugly syntax in case of parameterized types (casting the class object to a parameterized class type), just to satisfy the compiler.

Personally, I'd give up the guarding idea.

• It doesn't help at compile time (it only checks whether you were able to pass a clazz matching the consumer into function, not whether the actual object matches).

• It can check for some error cases at run time. But in cases like List, it still can't protect you from getting a ClassCastException later, thrown by the consumer. And that's what happens without your guard as well, just in more cases.