Reflection for Class of generic parameter in Java?

Imagine the following scenario:

class MyClass extends OtherClass<String>{

   String myName;
   //Whatever

}

class OtherClass<T> {

   T myfield;

}

And I am analyzing MyClass using reflection specifically (MyClass.class).getDeclaredFields(), in this case I will get the following fields (and Types, using getType() of the Field):

myName --> String
myField --> T

I want to get the actual Type for T, which is known at runtime due to the explicit "String" in the extends notation, how do I go about getting the non-genetic type of myField?

EDIT RESOLVED:

Seems like the answer is "you can't". For those who may look at this question later I'd recommend using Jackson (I was trying to do this to generate JSON) and annotating your classes and fields in such a way so that Jackson is aware of the inheritance hierarchy and can automatically do what the correct answer below suggested.

This can be achieved with reflection only because you explicitly used String, otherwise this information would've been lost due to type erasure.

ParameterizedType t = (ParameterizedType) MyClass.class.getGenericSuperclass(); // OtherClass<String>
Class<?> clazz = (Class<?>) t.getActualTypeArguments()[0]; // Class<String>

I found a nice explanation here:

When runtime inspecting a parameterizable type itself, like java.util.List, there is no way of knowing what type is has been parameterized to. This makes sense since the type can be parameterized to all kinds of types in the same application. But, when you inspect the method or field that declares the use of a parameterized type, you can see at runtime what type the paramerizable type was parameterized to.

In short:

You cannot see on a type itself what type it is parameterized to a runtime, but you can see it in fields and methods where it is used and parameterized.

In code:

You can't see T here:

class MyClass<T> { T myField; }

You can see the "T" here:

class FooClass {
    MyClass<? extends Serializable> fooField;
}

Here you would be able to tell the type and type parameters of fooField. See getGeneric*() methods of Class and Method.

By the way, I often see this (shortened):

Class fieldArgClass = (Class) aType.getActualTypeArguments()[0];

This is not correct, because getActualTypeArguments() may, and often will, return TypeVariable instead of class - that's when the generic is <? extends SomeClass> instead of just <SomeClass>. It can go deeper, imagine:

class FooClass {
    MyClass<? extends Map<String, List<? extends Serializable>>> fooField;
}

So you get a tree of Types. But that's a bit off-topic. Enjoy :)

This is a classic example of why reflection is not a great idea.

What you can get from a program by reflection are only those facts that the compiler people for the language chose to make available.

And they generally can't afford to make everything available; they'd sort of have to keep the raw program text around.

All the other facts about your code are thus not available to the reflectee.

The cure for this is to step outside the language and use a tool that can provide any arbitrary bit of information about the code. Such tools are called Program Transformation Systems (PTS).

A PTS parses the source code and builds an AST the represents it. A good PTW will build an AST that holds essentially everything about the code (operators, operands, punctuation, comments) so that it can be inspected. Normally a PTS will record the line/column position of language tokens so even layout information is available; extreme PTS will record the whitespace in the gaps between tokens or at least know how to read the original text file when necessary if asked about it. This AST is in essence the equivalent of the full text I said would be necessary, but in a more convenient form to process.

(PTSs have one other very nice property: they can modify the AST and regenerate code for the modified program. But that is above and beyond reflection so I won't comment further on this aspect).