Is there any use for Class.getTypeParameters()?

Question

This is a quote from another Thread in this forum:
How does erasure destroy reflection-related information? Methods getGenericInterfaces, getGenericSuperclass and getTypeParameters on java.lang.Class allow you to retrieve a lot of information on generic issues regarding a class. Obviously, that information is thus not destroyed.
While I do agree that Generics do not destroy reflection, I wonder what they add to it.
New types and methods are Class.getTypeParameters(), the interfaces java.lang.GenericDeclaration, java.lang.reflect.TypeParameter, java.lang.reflect.ParameterizedType etc...
Could someone please give me an example of what I could do with all these new types and methods?
It has been decided that Generics are implemented as a compile-time feature. At runtime, no information about the instantiated type parameters exists anymore. OK, so why clutter the core Java packages with a lot of seemingly useless new types and methods?

Answer 1

Could someone please give me an example of what I
could do with all these new types and methods?
It has been decided that Generics are implemented as a
compile-time feature. At runtime, no information about
the instantiated type parameters exists anymore. OK,
so why clutter the core Java packages with a lot of
seemingly useless new types and methods?This is a very good question, and something I've been wondering about myself. I cannot determine how to get the runtime to give me an instance of WildcardType or ParamaterizedType, for example.
Here's an extremely contrived example of how you can use Type bounds to effect runtime behaviour:
    class Processor<T> {       
    class StringProcessor<S extends String> extends Processor<S> {       
    public void whatKindOfProcessorIsItAnyway(Processor p) {
        Type processorType = p.getClass().getTypeParameters()[0].getBounds()[0];
        if ( String.class.equals(processorType) ) {
            System.out.println("I'm a string processor");
        } else {
            System.out.println("I process these: " + processorType);           
whatKindOfProcessorIsItAnyway(new StringProcessor<String>());
        whatKindOfProcessorIsItAnyway(new Processor<Integer>());Outputs:
I'm a string processor
I process these: class java.lang.Object
So you can see I can switch based on the type bounds compiled into the program, but I have no way of knowing that the second processor is actually instantiated with Integer, due to erasure.
Infact, the only reason I would know anything about the actual type argument in the first instance is because String is final so '? extends String' -> String, for what its worth.
Whether I can write a program that's actually useful using this information I've yet to determine, but I can imagine it could be useful for code generation.